Configuring the transport in JBoss

Configuring the transport of JMS Message is a key part of the messaging system tuning. Out of the box, HornetQ currently uses Netty as its high-performance low-level network library. Netty is a NIO client server framework, which enables quick and easy development of network applications, such as protocol servers and clients . It greatly simplifies and streamlines network programming, such as TCP and UDP socket server.

One of the most important concepts in HornetQ transports is the definition of acceptors and connectors.

An acceptor defines which type of connection is accepted by the HornetQ server. On the other hand a connector defines how to connect to a HornetQ server. The connector is used by a HornetQ client.

HornetQ defines two types of acceptor/connector:

invm: This type can be used when both HornetQ client and server run in the same Virtual Machine (invm for Intra Virtual Machine)

netty: This type must be used when HornetQ client and server run in different virtual machines (this connector type uses the netty project to handle the IO) To communicate, a HornetQ client must use a connector compatible with the server’s acceptor. A compatible client-server communication requires that it is carried on using the same type of acceptor/connector, as shown by the following image:

So, for example, it’s not possible to connect an InVM client connector to a Netty server acceptor. On the other hand, it’s possible to connect a Netty client connector to a Netty server acceptor, provided they are configured to run on the same host and port.

JBoss AS 7 comes with a preconfigured acceptor/connector pair, which is part of the JBoss messaging subsystem. We include them here:

As you can see, besides the in-vm acceptor/connector pair, each section defines two kinds of acceptors/connectors: one which relies on Netty defaults, named netty and another one (netty-throughput), which is specialized for higher messaging throughputs.

Frequently asked Jboss Interview Questions

You can further tune Netty TCP transport with a complete knowledge of the single parameters, which can be added to the acceptor/connector section. Here’s a comprehensive list of all parameters and their meaning:

One frequent source of confusion among HornetQ users is why connectors are included in the server configuration if the server is in charge to accept connections and deliver messages. There are two main reasons for this:

• Sometimes the server acts as a client itself when it connects to another server, for example, when one server is bridged to another, or when a server takes part in a cluster. In these cases, the server needs to know how to connect to other servers. That’s defined by connectors.
• If you’re using JMS and the server-side JMS services to instantiate JMS ConnectionFactory instances and bind them in JNDI, then when creating the HornetQConnectionFactory it needs to know what server that connection factory will create connections to.

Configuring connection factories The definition of connection-factory instances is included in the default server configuration:

A JMS ConnectionFactory object is used by the client to make connections to the server. You can find two Connection factory definitions:

• InVmConnectionFactory: This connection factory is bound under the entry java:/ConnectionFactory, and is used when server and client are part of the same process (that is, they are running in the same JVM).
• RemoteConnectionFactory: This connection factory, as the name implies, can be used when JMS connections are provided by a remote server, using Netty as connector.