<div class="wiki-content maincontent"><h2>Transport configuration options</h2><p>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.</p><structured-macro ac:macro-id="0f5649b8-41ab-477a-8bd2-7060071af7bd" ac:name="warning" ac:schema-version="1"><parameter ac:name="title">Be careful about whitespace</parameter><rich-text-body><p>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 <strong><code>failover:</code></strong> or&#160;<strong><code>static:</code></strong> URIs, do not put any whitespace around the <strong><code>','</code> </strong>symbol.</p></rich-text-body></structured-macro><h3>The AUTO Transport</h3><p>Starting with 5.13.0 ActiveMQ has support for automatic wire protocol detection over TCP, SSL, NIO, and NIO SSL. &#160;OpenWire, STOMP, AMQP, and MQTT are supported. &#160;For details see the <link><page ri:content-title="AUTO"></page><plain-text-link-body>AUTO </plain-text-link-body></link>Transport Reference.</p><h3>The VM Transport</h3><p>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.</p><p>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.</p><p>For more information see the <link><page ri:content-title="VM Transport Reference"></page></link></p><h3>The AMQP Transport</h3><p>As of 5.8.0 ActiveMQ has support for AMQP. For details see the <link><page ri:content-title="AMQP"></page></link> Transport Reference.</p><h3>The MQTT Transport</h3><p>Starting with 5.6.0 ActiveMQ also supports <a shape="rect" href="http://mqtt.org/">MQTT</a>. Its a light weight publish/subscribe messaging transport. See the <link><page ri:content-title="MQTT"></page></link> Transport Reference for details.</p><h3>The TCP Transport</h3><p>The TCP transport allows clients to connect a remote ActiveMQ using a a TCP socket.</p><p>For more information see the <link><page ri:content-title="TCP Transport Reference"></page></link></p><h3>The NIO Transport</h3><p>Same as the TCP transport, except that the <a shape="rect" href="http://en.wikipedia.org/wiki/New_I/O">New I/O (NIO)</a> package is used, which may provide better performance. The Java NIO package should not be confused with IBM's <a shape="rect" href="http://java.sys-con.com/read/46658.htm">AIO4J </a> package.</p><p>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.</p><structured-macro ac:macro-id="b963ed56-8d6d-409a-baee-d4a2ad19b668" ac:name="code" ac:schema-version="1"><plain-text-body>&lt;broker&gt;
  ...
  &lt;transportConnectors&gt;
    &lt;transportConnector name="nio" uri="nio://0.0.0.0:61616"/&gt;  
  &lt;/&lt;transportConnectors&gt;
  ...
&lt;/broker&gt;
</plain-text-body></structured-macro><p>Trying to use nio transport url on the client side will instantiate the regular TCP transport. For more information see the <link><page ri:content-title="NIO Transport Reference"></page></link></p><h3>The SSL Transport</h3><p>This allows you to talk over TCP using SSL. For more information see the <link><page ri:content-title="SSL Transport Reference"></page></link></p><h3>The NIO SSL Transport</h3><structured-macro ac:macro-id="2aa11976-d3d9-4a7a-98ff-b7ea8fb7f1f3" ac:name="info" ac:schema-version="1"><parameter ac:name="title">Availability</parameter><rich-text-body><p>Available since 5.6</p></rich-text-body></structured-macro><p>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</p><structured-macro ac:macro-id="65251e10-4456-410d-8bc8-a74670275b2d" ac:name="code" ac:schema-version="1"><plain-text-body>&lt;broker&gt;
  ...
  &lt;transportConnectors&gt;
    &lt;transportConnector name="nio+ssl" uri="nio+ssl://0.0.0.0:61616"/&gt;  
  &lt;/&lt;transportConnectors&gt;
  ...
&lt;/broker&gt;
</plain-text-body></structured-macro><p>Trying to use <code>nio+ssl</code> transport url on the client side will instantiate the regular SSL transport.</p><h3>The Peer Transport</h3><p>The Peer transport provides a peer-to-peer network with ActiveMQ. 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.</p><p>For more information see the <link><page ri:content-title="Peer Transport Reference"></page></link></p><h3>The UDP Transport</h3><p>This allows you to talk over UDP.</p><p>For more information see the <link><page ri:content-title="UDP Transport Reference"></page></link></p><h3>The Multicast Transport</h3><p>This allows you to talk over Multicast.</p><p>For more information see the <link><page ri:content-title="Multicast Transport Reference"></page></link></p><h3>The HTTP and HTTPS Transport</h3><p>This allows the ActiveMQ client and broker to tunnel over HTTP. If the client is not JMS you might want to look at <link><page ri:content-title="REST"></page></link> or <link><page ri:content-title="Ajax"></page></link> support instead.</p><p>For more information see the <link><page ri:content-title="HTTP and HTTPs Transports Reference"></page></link></p><h3>The WebSockets Transport</h3><p>This transport uses the new HTML5 WebSockets to exchange messages with the broker. For more information see the <link><page ri:content-title="WebSockets"></page></link> Transport Reference</p><h3>The Stomp Transport</h3><p>A plain text transport that can be used with many languages. See&#160;<link><page ri:content-title="Stomp"></page></link> for more details.</p><h2>General Purpose URIs</h2><p>You can configure other features via the URI syntax as follows...</p><h3>Connection Configuration URI</h3><p>Any Apache ActiveMQ JMS connection can be configured using the URL or explicitly setting properties on the <a shape="rect" href="http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/ActiveMQConnection.html">ActiveMQConnection</a> or <a shape="rect" href="http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html">ActiveMQConnectionFactory</a> objects themselves.</p><p>For more information see <link><page ri:content-title="Connection Configuration URI"></page></link></p><h3>Destination Options</h3><p>You can configure various consumer related options using <link><page ri:content-title="Destination Options"></page></link> which allow you to configure destinations using URI syntax.</p><h3>Broker Configuration URI</h3><p>You can use a <link><page ri:content-title="Broker Configuration URI"></page></link> to configure an embedded broker, either using the BrokerFactory helper class from Java or using the activemq shell script. For more details see <link><page ri:content-title="Run Broker"></page><plain-text-link-body>How to Run a Broker</plain-text-link-body></link></p><h3>Configuring Wire Formats</h3><p>Any transport which involves marshalling messages onto some kind of network transport like TCP or UDP will typically use the <link><page ri:content-title="OpenWire"></page></link> format. This is configurable to customize how things appear on the wire.</p><p>For more information see <link><page ri:content-title="Configuring Wire Formats"></page></link></p><h2>High Level Protocol URIs</h2><p>The following higher level protocols can be configured via URI</p><h3>The Failover Transport</h3><p>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 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.</p><p>For more information see the <link><page ri:content-title="Failover Transport Reference"></page></link></p><h3>The Fanout Transport</h3><p>The Fanout transport layers reconnect and replicate logic on top of any of the other transports. It is used replicate commands to multiple brokers.</p><p>For more information see the <link><page ri:content-title="Fanout Transport Reference"></page></link></p><h2>Using Discovery</h2><p>Often when using transports like TCP you want to use <link><page ri:content-title="Discovery"></page></link> to locate the available brokers. This is different from using, say, <link><page ri:content-title="Multicast Transport Reference"></page><plain-text-link-body>Multicast</plain-text-link-body></link> - as the actual main communication is over TCP but multicast is purely used to discover the location of brokers.</p><h3>The Discovery Transport</h3><p>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.</p><p>For more information see the <link><page ri:content-title="Discovery Transport Reference"></page></link></p><h3>The ZeroConf Transport</h3><p>The ZeroConf transport provides <link><page ri:content-title="Discovery"></page></link> and it works like the <link><page ri:content-title="Discovery Transport Reference"></page><plain-text-link-body>Discovery Transport</plain-text-link-body></link> but rather than using our own multicast based discovery mechanism (which allows you to configure the exact multicast address and port, etc.), the <link><page ri:content-title="ZeroConf"></page></link> transport is used instead.</p><p>For more information see the <link><page ri:content-title="ZeroConf Transport Reference"></page></link></p><h3>Server side options</h3><p>There are a number of options that can be used for changing behavior on the server for the&#160;<strong><code>TransportConnector</code></strong> in the ActiveMQ broker configuration. These are:</p><table><tbody><tr><th colspan="1" rowspan="1"><p>property name</p></th><th colspan="1" rowspan="1"><p>default</p></th><th colspan="1" rowspan="1"><p>description</p></th></tr><tr><td colspan="1" rowspan="1"><p><span style="color: red;"> <code>allowLinkStealing</code><br clear="none"></span></p></td><td colspan="1" rowspan="1"><p><code>false</code></p></td><td colspan="1" rowspan="1"><p>This is enabled for default for MQTT transport.</p><p>Link Stealing is where the last of two or more connections with the same id (clientID for JMS) is deemed the valid connection and the older one is closed by the broker.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>discoveryURI</code></p></td><td colspan="1" rowspan="1"><p><code>null</code></p></td><td colspan="1" rowspan="1"><p>If set, the multicast discovery address for client connections to find the broker.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>enableStatusMonitor</code></p></td><td colspan="1" rowspan="1"><p><code>false</code></p></td><td colspan="1" rowspan="1"><p>Will monitor connections to determine if they are blocked.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>name</code></p></td><td colspan="1" rowspan="1"><p><code>null</code></p></td><td colspan="1" rowspan="1"><p>The name of the&#160;<strong><code>TransportConnector</code></strong> instance.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>rebalanceClusterClients</code></p></td><td colspan="1" rowspan="1"><p><code>false</code></p></td><td colspan="1" rowspan="1"><p>Will automatically re-balance clients across the cluster on changes of topology.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>updateClusterClients</code></p></td><td colspan="1" rowspan="1"><p><code>false</code></p></td><td colspan="1" rowspan="1"><p>If enabled, will update client connections (if they use the&#160;<strong><code>failover://</code></strong> transport) of changes to the broker cluster.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>updateClusterClientsOnRemove</code></p></td><td colspan="1" rowspan="1"><p><code>false</code></p></td><td colspan="1" rowspan="1"><p>Will update clients if a broker is removed from the cluster.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>updateClusterFilter</code></p></td><td colspan="1" rowspan="1"><p><code>null</code></p></td><td colspan="1" rowspan="1"><p>Comma separated list of regular expressions. Brokers with a name matching the pattern will be included for client updates.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>uri</code></p></td><td colspan="1" rowspan="1"><p><code>null</code></p></td><td colspan="1" rowspan="1"><p>The bind address for the transport.</p></td></tr></tbody></table><structured-macro ac:macro-id="cc529423-17f8-4ab2-9dcb-305406ab27d0" ac:name="info" ac:schema-version="1"><rich-text-body><p><strong>Note</strong>: properties in <span style="color: rgb(255,0,0);">red</span> are version 5.10 (and higher) options only.</p></rich-text-body></structured-macro><p>Example configuration:</p><structured-macro ac:macro-id="7fbeb1d3-9c38-479d-b367-c1d8231f6bf8" ac:name="code" ac:schema-version="1"><parameter ac:name="language">xml</parameter><plain-text-body>&lt;broker&gt;
&#160;&#160; &lt;!-- ... --&gt;

&#160;&#160; &lt;transportConnectors&gt;
&#160;&#160;&#160;&#160; &lt;transportConnector name="openwire" uri="tcp://0.0.0.0:61616" enableStatusMonitor="true"/&gt; 
&#160;&#160; &lt;/&lt;transportConnectors&gt;

&#160;&#160; &lt;!-- ... --&gt;
&lt;/broker&gt;</plain-text-body></structured-macro></div>