Configuring Transports

Using ActiveMQ Classic > Configuring Transports

Transport configuration options

One of the first kinds of URI you are likely to use is a transport URI to connect to a broker using a kind of transport. Generally TCP or VM are the first transports you’ll use.

Be careful about whitespace

All of the following URI configurations are based on the java.net.URI class which does not allow whitespace to be used. So if you are using failover: or static: URIs, do not put any whitespace around the ',' symbol.

The AUTO Transport

Starting with 5.13.0 ActiveMQ Classic has support for automatic wire protocol detection over TCP, SSL, NIO, and NIO SSL.  OpenWire, STOMP, AMQP, and MQTT are supported.  For details see the AUTO Transport Reference.

The VM Transport

The VM transport allows clients to connect to each other inside the VM without the overhead of the network communication. The connection used is not that of a socket connection but instead uses direct method invocations to enable a high performance embedded messaging system.

The first client to use the VM connection will boot an embedded broker. Subsequent connections will attach that the same broker. Once all VM connections to the broker have been closed, the embedded broker will automatically shutdown.

For more information see the VM Transport Reference

The AMQP Transport

As of 5.8.0 ActiveMQ Classic has support for AMQP. For details see the AMQP Transport Reference.

The MQTT Transport

Starting with 5.6.0 ActiveMQ Classic also supports MQTT. Its a light weight publish/subscribe messaging transport. See the MQTT Transport Reference for details.

The TCP Transport

The TCP transport allows clients to connect a remote ActiveMQ Classic using a a TCP socket.

For more information see the TCP Transport Reference

The NIO Transport

Same as the TCP transport, except that the New I/O (NIO) package is used, which may provide better performance. The Java NIO package should not be confused with IBM’s AIO4J package.

To switch from TCP to NIO, simply change the scheme portion of the URI. Here’s an example as defined within a broker’s XML configuration file.

<broker>
  ...
  <transportConnectors>
    <transportConnector name="nio" uri="nio://0.0.0.0:61616"/>  
  </<transportConnectors>
  ...
</broker>

Trying to use nio transport url on the client side will instantiate the regular TCP transport. For more information see the NIO Transport Reference

The SSL Transport

This allows you to talk over TCP using SSL. For more information see the SSL Transport Reference

The NIO SSL Transport

Availability

Available since 5.6

Implementing SSL transport over NIO. This allows you to connect large number of SSL clients to a single broker instance. It’s server side transport-option only

<broker>
  ...
  <transportConnectors>
    <transportConnector name="nio+ssl" uri="nio+ssl://0.0.0.0:61616"/>  
  </<transportConnectors>
  ...
</broker>

Trying to use nio+ssl transport url on the client side will instantiate the regular SSL transport.

The Peer Transport

The Peer transport provides a peer-to-peer network with ActiveMQ Classic. What actually happens is the peer transport uses the VM transport to create and connect to a local embedded broker but which configures the embedded broker to establish network connections to other peer embedded brokers.

For more information see the Peer Transport Reference

The UDP Transport

This allows you to talk over UDP.

For more information see the UDP Transport Reference

The Multicast Transport

This allows you to talk over Multicast.

For more information see the Multicast Transport Reference

The HTTP and HTTPS Transport

This allows the ActiveMQ Classic client and broker to tunnel over HTTP. If the client is not JMS you might want to look at REST or Ajax support instead.

For more information see the HTTP and HTTPs Transports Reference

The WebSockets Transport

This transport uses the new HTML5 WebSockets to exchange messages with the broker. For more information see the WebSockets Transport Reference

The Stomp Transport

A plain text transport that can be used with many languages. See Stomp for more details.

General Purpose URIs

You can configure other features via the URI syntax as follows…

Connection Configuration URI

Any Apache ActiveMQ Classic JMS connection can be configured using the URL or explicitly setting properties on the ActiveMQConnection or ActiveMQConnectionFactory objects themselves.

For more information see Connection Configuration URI

Destination Options

You can configure various consumer related options using Destination Options which allow you to configure destinations using URI syntax.

Broker Configuration URI

You can use a Broker Configuration URI to configure an embedded broker, either using the BrokerFactory helper class from Java or using the activemq shell script. For more details see How to Run a Broker

Configuring Wire Formats

Any transport which involves marshalling messages onto some kind of network transport like TCP or UDP will typically use the OpenWire format. This is configurable to customize how things appear on the wire.

For more information see Configuring Wire Formats

High Level Protocol URIs

The following higher level protocols can be configured via URI

The Failover Transport

The Failover transport layers reconnect logic on top of any of the other transports. This is what used to be the Reliable transport in ActiveMQ Classic 3. Its configuration syntax allows you to specify any number of composite URIs. The Failover transport randomly chooses one of the composite URIs and attempts to establish a connection to it. If it does not succeed or if it subsequently fails, a new connection is established to one of the other URIs in the list.

For more information see the Failover Transport Reference

The Fanout Transport

The Fanout transport layers reconnect and replicate logic on top of any of the other transports. It is used replicate commands to multiple brokers.

For more information see the Fanout Transport Reference

Using Discovery

Often when using transports like TCP you want to use Discovery to locate the available brokers. This is different from using, say, Multicast - as the actual main communication is over TCP but multicast is purely used to discover the location of brokers.

The Discovery Transport

The Discovery transport works just like the reliable transport, except that it uses a discovery agent to locate the list of URIs to connect to.

For more information see the Discovery Transport Reference

The ZeroConf Transport

The ZeroConf transport provides Discovery and it works like the Discovery Transport but rather than using our own multicast based discovery mechanism (which allows you to configure the exact multicast address and port, etc.), the ZeroConf transport is used instead.

For more information see the ZeroConf Transport Reference

Server side options

There are a number of options that can be used for changing behavior on the server for the TransportConnector in the ActiveMQ Classic broker configuration. These are:

`Note**: properties in red are version 5.10 (and higher) options only.

Example configuration:

<broker>
   <!\-\- ... -->

   <transportConnectors>
     <transportConnector name="openwire" uri="tcp://0.0.0.0:61616" enableStatusMonitor="true"/> 
   </<transportConnectors>

   <!\-\- ... -->
</broker>