svn commit: r996308 [1/2] - in /websites/production/activemq/content: cache/main.pageCache failover-transport-reference.html stomp.html tcp-transport-reference.html

[bu...@apache.org]

Author: buildbot
Date: Tue Aug 30 20:22:21 2016
New Revision: 996308

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/failover-transport-reference.html
    websites/production/activemq/content/stomp.html
    websites/production/activemq/content/tcp-transport-reference.html

Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/activemq/content/failover-transport-reference.html
==============================================================================
--- websites/production/activemq/content/failover-transport-reference.html (original)
+++ websites/production/activemq/content/failover-transport-reference.html Tue Aug 30 20:22:21 2016
@@ -70,7 +70,7 @@
 <p></p>
         <div class="top_red_bar">
           <div id="site-breadcrumbs">
-<a href="using-activemq-4.html">Using ActiveMQ 4</a>&nbsp;&gt;&nbsp;<a href="configuring-transports.html">Configuring Transports</a>&nbsp;&gt;&nbsp;<a href="activemq-4-connection-uris.html">ActiveMQ 4 Connection URIs</a>&nbsp;&gt;&nbsp;<a href="failover-transport-reference.html">Failover Transport Reference</a>
+<a href="using-activemq.html">Using ActiveMQ</a>&nbsp;&gt;&nbsp;<a href="configuring-transports.html">Configuring Transports</a>&nbsp;&gt;&nbsp;<a href="activemq-connection-uris.html">ActiveMQ Connection URIs</a>&nbsp;&gt;&nbsp;<a href="failover-transport-reference.html">Failover Transport Reference</a>
           </div>
           <div id="site-quicklinks">
 <p><a shape="rect" href="download.html">Download</a> | <a shape="rect" class="external-link" href="http://activemq.apache.org/maven/apidocs/index.html">JavaDocs</a> <a shape="rect" href="javadocs.html">More...</a> | <a shape="rect" href="source.html">Source</a> | <a shape="rect" href="discussion-forums.html">Forums</a> | <a shape="rect" href="support.html">Support</a></p>
@@ -84,13 +84,13 @@
 <div class="wiki-content maincontent"><h3 id="FailoverTransportReference-TheFailoverTransport">The Failover Transport</h3><p>The Failover transport layers reconnect logic on top of any of the other transports. The 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 choosing one of the other URIs randomly from the list.</p><h4 id="FailoverTransportReference-ConfigurationSyntax">Configuration Syntax</h4><p><code><strong>failover:(uri1,...,uriN)?transportOptions&amp;nestedURIOptions</strong></code></p><p>or</p><p><code><strong>failover:uri1,...,uriN</strong></code></p><h5 id="FailoverTransportReference-UsingRandomize">Using Randomize</h5><p>The Failover transport chooses a URI at <code>random</code> by default. This effectively load-balances clients over multiple brokers.
  However, to have a client connect to a primary first and only connect to a secondary backup broker when the primary is unavailable, set <strong><code>randomize=false</code></strong>. For example:</p><p>&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
 <pre>failover:(tcp://primary:61616,tcp://secondary:61616)?randomize=false
 </pre>
-</div></div><h5 id="FailoverTransportReference-TransportOptions">Transport Options</h5><p>&#160;</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Option Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default Value</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>initialReconnectDelay</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>10</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The delay (in ms) before the <em>first</em> reconnect attempt.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxReconnectDelay</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>30000</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The maximum delay (in ms) between the <em>second and subsequent</em> reconnect 
 attempts.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>useExponentialBackOff</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong> an exponential back-off is used between reconnect attempts.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>reconnectDelayExponent</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>2.0</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The exponent used during exponential back-off attempts.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxReconnectAttempts</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>-1 | 0</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><em>From</em> ActiveMQ 5.6: default is <strong><code>-1</code></strong>, retry forever. <strong><code>0</c
 ode></strong> means disables re-connection, e.g: just try to connect once.<br clear="none" class="atl-forced-newline"> <em>Before</em> ActiveMQ 5.6: default is <strong><code>0</code></strong>, retry forever. <br clear="none" class="atl-forced-newline"> <em>All versions</em>: a value <strong><code>&gt;0</code></strong> denotes the maximum number of reconnect attempts before an error is sent back to the client.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>startupMaxReconnectAttempts</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>-1</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A value of <strong><code>-1</code></strong> denotes that the number of connection attempts at startup should be unlimited.</p><p>A value of&#160; <strong><code>&gt;=0 </code></strong>denotes the number of reconnect attempts at startup that will be made after which an error is sent back to the client when the client makes a subsequent re
 connect attempt.</p><p><strong>Note</strong>: once successfully connected the <code><strong>maxReconnectAttempts</strong></code> option prevails.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>randomize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong>, choose a URI at random from the list to use for reconnect.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>backup</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Initialize and hold a second transport connection - to enable fast failover.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>timeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>-1</code></p></td><td colspan="1" rowspan="1" class="confluenc
 eTd"><p>Set the timeout on send operations (in ms) without interruption of re-connection process. <strong>Since ActiveMQ 5.3</strong>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>trackMessages</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Keep a cache of in-flight messages that will flushed to a broker on reconnect.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxCacheSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>131072</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Size in bytes for the cache of tracked messages. Applicable only if <strong><code>trackMessages</code></strong> is <strong><code>true</code></strong>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateURIsSupported</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>
 <code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Determines whether the client should accept updates from the broker to its list of known URIs. <strong>Since</strong><strong> ActiveMQ 5.4.</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateURIsURL</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A URL (or path to a local file) to a text file containing a comma separated list of URIs to use for reconnect in the case of failure.&#160;<strong>Since ActiveMQ 5.4.</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>nested.*</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Common URI options that will be applied to each URI in the list. <strong>Since ActiveMQ 5.9.</strong></p></td></tr><tr><td colspan=
 "1" rowspan="1" class="confluenceTd"><p><code>warnAfterReconnectAttempts</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>10</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A value <strong><code>&gt;0</code></strong> specifies the number of reconnect attempts before a warning is logged. A logged warning indicates that there is no current connection but re-connection is being attempted.</p><p>A value of <strong><code>&lt;=0</code></strong> disables the logging of warnings about reconnect attempts. <strong>Since ActiveMQ 5.10.</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>reconnectSupported</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Determines whether the client should respond to broker <strong><code>ConnectionControl</code></strong> events with a reconnect (see: <strong><code>rebalanceClusterClients</cod
 e>).</strong></p></td></tr></tbody></table></div><h5 id="FailoverTransportReference-ExampleURI">Example URI</h5><p>&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
+</div></div><h5 id="FailoverTransportReference-TransportOptions">Transport Options</h5><p>&#160;</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Option Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default Value</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>backup</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Initialize and hold a second transport connection - to enable fast failover.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>initialReconnectDelay</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>10</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The delay (in ms) before the <em>first</em> reconnect attempt.</p></td></tr>
 <tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxCacheSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>131072</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Size in bytes for the cache of tracked messages.</p><p>Applicable only if <strong><code>trackMessages</code></strong> is <strong><code>true</code></strong>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxReconnectAttempts</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>-1 | 0</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><em>From</em> ActiveMQ 5.6: default is <strong><code>-1</code></strong>, retry forever. <strong><code>0</code></strong> means disables re-connection, e.g: just try to connect once.<br clear="none" class="atl-forced-newline"> <em>Before</em> ActiveMQ 5.6: default is <strong><code>0</code></strong>, retry forever. <br clear="none" class="atl-forced-newline"> <em>All versions
 </em>: a value <strong><code>&gt;0</code></strong> denotes the maximum number of reconnect attempts before an error is sent back to the client.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxReconnectDelay</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>30000</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The maximum delay (in ms) between the <em>second and subsequent</em> reconnect attempts.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>nested.*</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Common URI options that will be applied to each URI in the list. <strong>Since ActiveMQ 5.9.</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>randomize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" 
 rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong>, choose a URI at random from the list to use for reconnect.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>reconnectDelayExponent</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>2.0</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The exponent used during exponential back-off attempts.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>reconnectSupported</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Determines whether the client should respond to broker <strong><code>ConnectionControl</code></strong> events with a reconnect (see: <strong><code>rebalanceClusterClients</code>).</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>startupMaxReconnectAttempts</code></p></td><td colspan="1" row
 span="1" class="confluenceTd"><p><code>-1</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A value of <strong><code>-1</code></strong> denotes that the number of connection attempts at startup should be unlimited.</p><p>A value of&#160; <strong><code>&gt;=0 </code></strong>denotes the number of reconnect attempts at startup that will be made after which an error is sent back to the client when the client makes a subsequent reconnect attempt.</p><p><strong>Note</strong>: once successfully connected the <code><strong>maxReconnectAttempts</strong></code> option prevails.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>timeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>-1</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Set the timeout on send operations (in ms) without interruption of re-connection process. <strong>Since ActiveMQ 5.3</strong>.</p></td></tr><tr><td colspan="1" rowspan="1" class=
 "confluenceTd"><p><code>trackMessages</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Keep a cache of in-flight messages that will flushed to a broker on reconnect.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateURIsSupported</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Determines whether the client should accept updates from the broker to its list of known URIs. <strong>Since</strong><strong> ActiveMQ 5.4.</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateURIsURL</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A URL (or path to a local file) to a text file containing a comma separated list of URIs to use for reconnect i
 n the case of failure.&#160;<strong>Since ActiveMQ 5.4.</strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>useExponentialBackOff</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong> an exponential back-off is used between reconnect attempts.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>warnAfterReconnectAttempts</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>10</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A value <strong><code>&gt;0</code></strong> specifies the number of reconnect attempts before a warning is logged. A logged warning indicates that there is no current connection but re-connection is being attempted.</p><p>A value of <strong><code>&lt;=0</code></strong> disables the logging of warnings about reconnect attempts. <strong>Since Acti
 veMQ 5.10.</strong></p></td></tr></tbody></table></div><h5 id="FailoverTransportReference-ExampleURI">Example URI</h5><p>&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
 <pre>failover:(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
 </pre>
-</div></div><h5 id="FailoverTransportReference-Notes">Notes</h5><p>Under the Failover transport send operations will, by default, block indefinitely when the broker becomes unavailable. There are two options available for handling this scenario. First, either set a <a shape="rect" class="external-link" href="http://activemq.apache.org/maven/5.5.0/activemq-core/apidocs/org/apache/activemq/transport/TransportListener.html">TransportListener</a> directly on the <a shape="rect" class="external-link" href="http://activemq.apache.org/maven/5.5.0/activemq-core/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html#setTransportListener(org.apache.activemq.transport.TransportListener)">ActiveMQConnectionFactory</a>, so that it is in place before any request that may require a network hop or second, set the <strong><code>timeout</code></strong> option. The <strong><code>timeout</code></strong> option causes the current send operation to fail after the specified timeout. For example:</p><p
 >&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
+</div></div><h5 id="FailoverTransportReference-Notes">Notes</h5><p>Under the Failover transport send operations will, by default, block indefinitely when the broker becomes unavailable. There are two options available for handling this scenario. First, either set a <a shape="rect" class="external-link" href="http://activemq.apache.org/maven/apidocs/org/apache/activemq/transport/TransportListener.html">TransportListener</a> directly on the <a shape="rect" class="external-link" href="http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html">ActiveMQConnectionFactory</a>, so that it is in place before any request that may require a network hop or second, set the <strong><code>timeout</code></strong> option. The <strong><code>timeout</code></strong> option causes the current send operation to fail after the specified timeout. For example:</p><p>&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelCon
 tent">
 <pre>failover:(tcp://primary:61616)?timeout=3000
 </pre>
-</div></div><p>In this example if the connection isn't established the send operation will timeout after 3 seconds. It is important to note that the connection <em>is not killed</em> when a timeout occurs. It is possible, therefore, to resend the affected message(s) later using the <em>same</em> connection once a broker becomes available.</p><h5 id="FailoverTransportReference-Transactions">Transactions</h5><p>The Failover transport tracks transactions by default. In-flight transactions are replayed upon re-connection. For simple scenarios this works as expected. However, there is an assumption regarding acknowledged (or consumer) transactions in that the previously received messages will automatically be replayed upon re-connection. This, however, is not always true when there are many connections and consumers, as re-delivery order is not guaranteed as stale outstanding acknowledgements can interfere with newly delivered messages. This can lead to unacknowledged messages.</p><p>Sta
 rting in version 5.3.1, however, re-delivery order <em>is</em> tracked and a transaction will fail to commit if outstanding messages are not redelivered after failover. A <strong><code>javax.jms.</code><code>TransactionRolledBackException</code></strong> is thrown if the commit fails. In doubt transactions will result in a rollback such that they can be replayed by the application. In doubt transactions occur when failover happens when a commit message is in-flight. It is not possible to know the exact point of failure. Did failure happen because the transaction commit message was not delivered or was the commit reply lost? In either case, it becomes necessary to rollback the transaction so that the application can get an indication of the failure and deal with any potential problem.</p><h5 id="FailoverTransportReference-Broker-sideOptionsforFailover">Broker-side Options for Failover</h5><p><span style="color: red;"><strong><em>This is new in version 5.4:</em></strong></span></p><p>
 The TransportConnector has options available so that the broker can update clients automatically regarding information of about the presence new brokers available for failover. The options are:</p><p>&#160;</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Option Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default Value</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateClusterClients</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If&#160;<strong><code>true</code></strong>, pass information to connected clients about changes in the topology of the broker cluster.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>rebalanceClusterClients</code></p></td><td colspan="1" rows
 pan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong>, connected clients will be asked to re-balance across a cluster of brokers when a new broker joins the network of brokers (note:&#160;<strong><code>priorityBackup=true</code></strong> can override).</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateClusterClientsOnRemove</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong>, will update clients when a cluster is removed from the network. Having this as separate option enables clients to be updated when new brokers join, but <em>not</em> when brokers leave.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateClusterFilter</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</c
 ode></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Comma separated list of regular expression filters used to match broker names of brokers to designate as being part of the failover cluster for the clients.</p></td></tr></tbody></table></div><p>For example:</p><p>&#160;</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>In this example if the connection isn't established the send operation will timeout after 3 seconds. It is important to note that the connection <em>is not killed</em> when a timeout occurs. It is possible, therefore, to resend the affected message(s) later using the <em>same</em> connection once a broker becomes available.</p><h5 id="FailoverTransportReference-Transactions">Transactions</h5><p>The Failover transport tracks transactions by default. In-flight transactions are replayed upon re-connection. For simple scenarios this works as expected. However, there is an assumption regarding acknowledged (or consumer) transactions in that the previously received messages will automatically be replayed upon re-connection. This, however, is not always true when there are many connections and consumers, as re-delivery order is not guaranteed as stale outstanding acknowledgements can interfere with newly delivered messages. This can lead to unacknowledged messages.</p><p>Sta
 rting in version 5.3.1, however, re-delivery order <em>is</em> tracked and a transaction will fail to commit if outstanding messages are not redelivered after failover. A <strong><code>javax.jms.</code><code>TransactionRolledBackException</code></strong> is thrown if the commit fails. In doubt transactions will result in a rollback such that they can be replayed by the application. In doubt transactions occur when failover happens when a commit message is in-flight. It is not possible to know the exact point of failure. Did failure happen because the transaction commit message was not delivered or was the commit reply lost? In either case, it becomes necessary to rollback the transaction so that the application can get an indication of the failure and deal with any potential problem.</p><h5 id="FailoverTransportReference-Broker-sideOptionsforFailover">Broker-side Options for Failover</h5><p><span style="color: red;"><strong><em>This is new in version 5.4:</em></strong></span></p><p>
 The&#160;<strong><code>TransportConnector</code></strong> has options available so that the broker can update clients automatically regarding information of about the presence new brokers available for failover. The options are:</p><p>&#160;</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Option Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default Value</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateClusterClients</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If&#160;<strong><code>true</code></strong>, pass information to connected clients about changes in the topology of the broker cluster.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>rebalanceClusterClients<
 /code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong>, connected clients will be asked to re-balance across a cluster of brokers when a new broker joins the network of brokers (note:&#160;<strong><code>priorityBackup=true</code></strong> can override).</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateClusterClientsOnRemove</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>If <strong><code>true</code></strong>, will update clients when a cluster is removed from the network. Having this as separate option enables clients to be updated when new brokers join, but <em>not</em> when brokers leave.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>updateClusterFilter</code></p></td><td colspan="1" rowspan="1" cl
 ass="confluenceTd"><p><code>null</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Comma separated list of regular expression filters used to match broker names of brokers to designate as being part of the failover cluster for the clients.</p></td></tr></tbody></table></div><p>For example:</p><p>&#160;</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: xml; gutter: false; theme: Confluence" style="font-size:12px;">&lt;broker&gt;
   ...
   &lt;transportConnectors&gt;
@@ -99,7 +99,7 @@
   ...
 &lt;/broker&gt;
 </pre>
-</div></div><p>If <strong><code>updateClusterClients=true</code></strong>, then clients only need to be configured with the details of one broker within a cluster to connect to. For example:</p><p>&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
+</div></div><p>If <strong><code>updateClusterClients=true</code></strong> then clients only need to be configured with the details of one broker within a cluster to connect to. For example:</p><p>&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
 <pre>failover:(tcp://primary:61616)
 </pre>
 </div></div><p>when new brokers join the cluster the client is automatically informed of the new broker's URI. The new URI is then available for failover when one of the other known brokers becomes unavailable.</p><h6 id="FailoverTransportReference-MoreInformation">More Information</h6><p>Also check out the following blog entry about using the cluster client updates and re-balancing features titled <a shape="rect" class="external-link" href="http://bsnyderblog.blogspot.com/2010/10/new-features-in-activemq-54-automatic.html" rel="nofollow">New Features in ActiveMQ 5.4: Automatic Cluster Update and Rebalance</a>.</p><h5 id="FailoverTransportReference-PriorityBackup">Priority Backup</h5><p>If brokers are available in both local and remote networks, it's possible to specify a preference for local brokers over remote brokers using the <strong><code>priorityBackup</code></strong> and <strong><code>priorityURIs</code></strong> options (since ActiveMQ 5.6). Consider the following URL:</p><p
 >&#160;</p><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">

Modified: websites/production/activemq/content/stomp.html
==============================================================================
--- websites/production/activemq/content/stomp.html (original)
+++ websites/production/activemq/content/stomp.html Tue Aug 30 20:22:21 2016
@@ -87,24 +87,23 @@
    &lt;transportConnector name="stomp" uri="stomp://localhost:61613"/&gt;
 &lt;/transportConnectors&gt;
 </pre>
-</div></div><p>To see a full example, try <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/activemq/trunk/assembly/src/release/example/conf/activemq.xml">this XML</a>. If you save that XML as foo.xml then you can run stomp via the command line as</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>To see a full example, try <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/activemq/trunk/assembly/src/release/example/conf/activemq.xml">this XML</a>. If you save that XML as&#160;<strong><code>foo.xml</code></strong> then you can run stomp via the command line as</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">activemq xbean:foo.xml
 </pre>
-</div></div><p>For more help see <a shape="rect" href="run-broker.html">Run Broker</a>.</p><h3 id="Stomp-TheStompWireFormat">The Stomp Wire Format</h3><p>Stomp uses a text based wire format that can be configured with the following options. &#160;All options can be configured on a Brokers transport bind URI.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Parameter Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default Value</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>maxDataLength</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>104857600</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Maximum size of the message body (content) that can be sent.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>maxFrameSize</p></td><td colspan="1" rowspan="1" class="conflu
 enceTd"><p>MAX_LONG</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(v5.12.0) Maximum frame size that can be sent. A Stomp frame includes a command, optional headers, and an optional body. Can help help prevent OOM DOS attacks</p></td></tr></tbody></table></div><p>All options must be prepended with&#160;<code>wireFormat</code>&#160;in order to take effect. Without this proper formatting, the option will have zero effect.</p><h4 id="Stomp-ExampleWireFormatConfiguration">Example Wire Format Configuration<br clear="none">&#160;</h4><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">     &lt;transportConnector name="stomp+ssl" uri="stomp+ssl://localhost:61612?wireFormat.maxFrameSize=1000000"/&gt;</pre>
-</div></div><h3 id="Stomp-Security">Security</h3><p>Stomp implementation fully supports an <a shape="rect" href="security.html">ActiveMQ security</a> mechanism. This means that the <code>CONNECT</code> command will return an <code>ERROR</code> frame on unsuccessful authentication. Also, the authorization policies will be applied when you try to access (read/write) certain destinations. If you use synchronous operations (by using <a shape="rect" class="external-link" href="http://stomp.github.com/stomp-specification-1.1.html#RECEIPT" rel="nofollow">receipts</a>), you can expect an <code>ERROR</code> frame in case of unauthorized access attempt. In other case, operations will be discarded but the client will not be informed of errors. This also stands for all other errors that can happen on the broker side.</p><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Availability</p><span class="aui-icon aui-icon-small aui-iconfont-info conflu
 ence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Stomp security implementation is available from version 5.1 onwards.</p></div></div><div class="confluence-information-macro confluence-information-macro-tip"><p class="title">SSL</p><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>For additional security, you can use Stomp over SSL as described in the following section.</p></div></div><h3 id="Stomp-EnablingStompoverNIO">Enabling Stomp over NIO</h3><p>For better scalability (and performance) you might want to run Stomp protocol over NIO transport. To do that just use <code>stomp+nio</code> transport prefix instead of <code>stomp</code>. For example, add the following transport configuration in your XML file</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">     &lt;transportConnector name="stomp+nio" uri="stomp+nio://localhost:61612"/&gt;
+</div></div><p>For more help see <a shape="rect" href="run-broker.html">Run Broker</a>.</p><h3 id="Stomp-TheStompWireFormat">The Stomp Wire Format</h3><p>Stomp uses a text based wire format that can be configured with the following options. &#160;All options can be configured on a Brokers transport bind URI.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Parameter Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default Value</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxDataLength</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>104857600</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Maximum size of the message body (content) that can be sent.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxFrameSize</code></p></td><t
 d colspan="1" rowspan="1" class="confluenceTd"><p><code>MAX_LONG</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(v5.12.0) Maximum frame size that can be sent. A Stomp frame includes a command, optional headers, and an optional body. Can help help prevent OOM DOS attacks</p></td></tr></tbody></table></div><div class="confluence-information-macro confluence-information-macro-warning"><p class="title">Use the Correct Prefix!</p><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Wire format options must have the prefix&#160;<strong><code>wireFormat.</code></strong> to take effect, e.g.,&#160;<strong><code>wireFormat.<code>maxDataLength</code>=100000</code></strong>. Options missing this prefix will be ignored.</p></div></div><h4 id="Stomp-ExampleWireFormatConfiguration">Example Wire Format Configuration<br clear="none">&#160;</h4><div class="code panel pdl" style="border-
 width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;transportConnector name="stomp+ssl" uri="stomp+ssl://localhost:61612?wireFormat.maxFrameSize=1000000"/&gt;</pre>
+</div></div><h3 id="Stomp-Security">Security</h3><p>Stomp implementation fully supports an <a shape="rect" href="security.html">ActiveMQ security</a> mechanism. This means that the <strong><code>CONNECT</code></strong> command will return an <strong><code>ERROR</code></strong> STOMP frame on unsuccessful authentication. Also, the authorization policies will be applied when you try to access (read/write) certain destinations. If you use synchronous operations (by using <a shape="rect" class="external-link" href="http://stomp.github.com/stomp-specification-1.1.html#RECEIPT" rel="nofollow">receipts</a>), you can expect an <code>ERROR</code> frame in case of unauthorized access attempt. In other case, operations will be discarded but the client will not be informed of errors. This also stands for all other errors that can happen on the broker side.</p><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Availability</p><span class="aui-icon
  aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Stomp security implementation is available from version 5.1 on.</p></div></div><div class="confluence-information-macro confluence-information-macro-tip"><p class="title">SSL</p><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>For additional security, you can use Stomp over SSL as described in the following section.</p></div></div><h3 id="Stomp-EnablingStompoverNIO">Enabling Stomp over NIO</h3><p>For better scalability (and performance) you might want to run Stomp protocol over NIO transport. To do that just use <strong><code>stomp+nio</code></strong> transport prefix instead of <code>stomp</code>. For example, add the following transport configuration in your XML file</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelConte
 nt pdl">
+<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;transportConnector name="stomp+nio" uri="stomp+nio://localhost:61612"/&gt;
 </pre>
-</div></div><p>This transport use <a shape="rect" class="external-link" href="http://activemq.apache.org/configuring-transports.html#ConfiguringTransports-TheNIOTransport">NIO transport</a> underneath and will generally use much less threads than standard connector. This connector can help if you want to use <a shape="rect" class="external-link" href="http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html">large number of queues</a></p><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Availability</p><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Stomp Nio connector implementation is available in version 5.3 and up.</p></div></div><h3 id="Stomp-EnablingStompoverSSL">Enabling Stomp over SSL</h3><p>It's easy to configure ActiveMQ to use Stomp over SSL connection. All you have to do is use <code>stom
 p+ssl</code> transport prefix instead of <code>stomp</code>. For example, add the following transport configuration in your XML file</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">     &lt;transportConnector name="stomp+ssl" uri="stomp+ssl://localhost:61612"/&gt;
+</div></div><p>This transport use <a shape="rect" class="external-link" href="http://activemq.apache.org/configuring-transports.html#ConfiguringTransports-TheNIOTransport">NIO transport</a> underneath and will generally use much less threads than standard connector. This connector can help if you want to use <a shape="rect" class="external-link" href="http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html">large number of queues</a></p><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Availability</p><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Stomp NIO connector implementation is available in version 5.3 and up.</p></div></div><h3 id="Stomp-EnablingStompoverSSL">Enabling Stomp over SSL</h3><p>It's easy to configure ActiveMQ to use Stomp over SSL connection. All you have to do is use <strong><c
 ode>stomp+ssl</code></strong> transport prefix instead of <code>stomp</code>. For example, add the following transport configuration in your XML file</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;transportConnector name="stomp+ssl" uri="stomp+ssl://localhost:61612"/&gt;
 </pre>
-</div></div><ul><li>For more details on using SSL with ActiveMQ see the following article (<a shape="rect" class="external-link" href="http://activemq.apache.org/how-do-i-use-ssl.html">How do I use SSL</a>).</li><li>Example of using Stomp over SSL on the client side could be found in the <a shape="rect" class="external-link" href="http://stomp.fusesource.org/documentation/php/book.html#SSL" rel="nofollow">PHP Stomp client example </a>.</li></ul><h3 id="Stomp-Heart-beatgraceperiods">Heart-beat grace periods</h3><p>The STOMP protocol (version 1.1 or greater) <a shape="rect" class="external-link" href="http://stomp.github.io/stomp-specification-1.2.html#Heart-beating" rel="nofollow">defines the concept of heart beats</a> as a method by which a client and broker can determine the health of the underlying TCP connection between them.</p><p>ActiveMQ offers support for STOMP defined heart beating provided the client is using version 1.1 (or greater) of the protocol. Prior to ActiveMQ 5.9.0
 , however, the enforcement of the 'read' heart-beat timeout (that is, a heart-beat sent from the client to the broker) was strict. In other words, the broker was intolerant of late arriving read heart-beats from the client. This resulted in the broker concluding that the client was no longer present causing it to close its side of the client's connection when the client failed to honor it's configured heart-beat settings.</p><p>As of version 5.9.0 the timeout enforcement for read heart-beats is now configurable via a new transport option,<br clear="none"> <strong>transport.hbGracePeriodMultiplier</strong>:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><ul><li>For more details on using SSL with ActiveMQ see the following article (<a shape="rect" class="external-link" href="http://activemq.apache.org/how-do-i-use-ssl.html">How do I use SSL</a>).</li><li>Example of using Stomp over SSL on the client side could be found in the <a shape="rect" class="external-link" href="http://stomp.fusesource.org/documentation/php/book.html#SSL" rel="nofollow">PHP Stomp client example </a>.</li></ul><h3 id="Stomp-Heart-beatgraceperiods">Heart-beat grace periods</h3><p>The STOMP protocol (version 1.1 or greater) <a shape="rect" class="external-link" href="http://stomp.github.io/stomp-specification-1.2.html#Heart-beating" rel="nofollow">defines the concept of heart beats</a> as a method by which a client and broker can determine the health of the underlying TCP connection between them.</p><p>ActiveMQ offers support for STOMP defined heart beating provided the client is using version 1.1 (or greater) of the protocol. Prior to ActiveMQ 5.9.0
 , however, the enforcement of the 'read' heart-beat timeout (that is, a heart-beat sent from the client to the broker) was strict. In other words, the broker was intolerant of late arriving read heart-beats from the client. This resulted in the broker concluding that the client was no longer present causing it to close its side of the client's connection when the client failed to honor it's configured heart-beat settings.</p><p>As of version 5.9.0 the timeout enforcement for read heart-beats is now configurable via a new transport option&#160;<strong><code>transport.hbGracePeriodMultiplier</code></strong>:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;transportConnectors&gt;
-   &lt;transportConnector name="stomp"
-uri="stomp://localhost:61613?transport.hbGracePeriodMultiplier=1.5"/&gt;
+   &lt;transportConnector name="stomp" uri="stomp://localhost:61613?transport.hbGracePeriodMultiplier=1.5"/&gt;
 &lt;/transportConnectors&gt;
 </pre>
-</div></div><p>This multiplier is used to calculate the effective read heart-beat timeout the broker will enforce for each client's connection. The multiplier is applied to the read-timeout interval the client specifies in its CONNECT frame:</p><p>&lt;client specified read heart-beat interval&gt; * &lt;grace periodmultiplier&gt; == &lt;broker enforced read heart-beat timeout interval&gt;</p><p>For backward compatibility, if the grace period multiplier is not configured the default enforcement mode remains strict, e.g., transport.hbGracePeriodMultiplier=1.0. Attempts to configure the grace period multiplier to a value less than, or equal to 1.0 will be silently ignored.</p><p>STOMP clients that wish to be tolerant of late arriving heart-beats from the broker must implement their own solution for doing so.</p><ul><li>Please check the <a shape="rect" class="external-link" href="http://stomp.github.io/stomp-specification-1.2.html#Heart-beating" rel="nofollow">STOMP specification</a> for
  the details on heart-beating</li><li>The JIRA that implemented this: <a shape="rect" class="external-link" href="https://issues.apache.org/jira/browse/AMQ-4674">ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol</a></li></ul><h3 id="Stomp-WorkingwithDestinationswithStomp">Working with Destinations with Stomp</h3><p>Note that the prefix in stomp <strong>/queue/</strong> or <strong>/topic/</strong> is removed from the string before passing it to ActiveMQ as a JMS destination. Also note that the default separator in MOM systems is . (DOT). So <strong>FOO.BAR</strong> is the normal syntax of a MOM queue - the Stomp equivalent would be <strong>/queue/FOO.BAR</strong></p><div class="confluence-information-macro confluence-information-macro-warning"><p class="title">Be careful about starting destinations with /</p><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluen
 ce-information-macro-body"><p>If in Stomp world you use <strong>/queue/foo/bar</strong> then in a JMS world the queue would be called <strong>foo/bar</strong> not <strong>/foo/bar</strong>.</p></div></div><h3 id="Stomp-PersistenceofStompmessages">Persistence of Stomp messages</h3><p>By default, Stomp produced messages are set to non-persistent. You have to explicitly tell your Stomp library to add "persistent:true" to all SEND requests, for any messages that you want to persist across ActiveMQ restarts. This is the opposite of the default for JMS submitted messages.</p><h3 id="Stomp-WorkingwithJMSText/BytesMessagesandStomp">Working with JMS Text/Bytes Messages and Stomp</h3><p>Stomp is a very simple protocol - that's part of the beauty of it! As such, it does not have knowledge of JMS messages such as TextMessages or BytesMessages. The protocol does however support a content-length header. To provide more robust interaction between Stomp and JMS clients, ActiveMQ keys off of the inc
 lusion of this header to determine what message type to create when sending from Stomp to JMS. The logic is simple:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Inclusion of content-length header</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Resulting Message</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>yes</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>BytesMessage</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>no</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>TextMessage</p></td></tr></tbody></table></div><p>This same logic can be followed when going from JMS to Stomp, as well. A Stomp client could be written to key off of the inclusion of the content-length header to determine what type of message structure to provide to the user.</p><h3 id="Stomp-Messagetransformations">Message transformations</h3><p>The <code>transform
 ation</code> message header on <code>SEND</code> and <code>SUBSCRIBE</code> messages could be used to instruct ActiveMQ to transform messages from text to the format of your desire. Currently, ActiveMQ comes with a transformer that can transform XML/JSON text to Java objects, but you can add your own transformers as well.</p><p>Here's a quick example of how to use built-in transformer (taken from test cases)</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>This multiplier is used to calculate the effective read heart-beat timeout the broker will enforce for each client's connection. The multiplier is applied to the read-timeout interval the client specifies in its&#160;<strong><code>CONNECT</code></strong> frame:</p><p><code>&#160; <strong>&lt;client specified read heart-beat interval&gt; * &lt;grace periodmultiplier&gt; == &lt;broker enforced read heart-beat timeout interval&gt;</strong></code></p><p>For backward compatibility, if the grace period multiplier is not configured the default enforcement mode remains strict, e.g.,&#160;<strong><code>transport.hbGracePeriodMultiplier=1.0</code></strong>. Attempts to configure the grace period multiplier to a value less than, or equal to 1.0 will be silently ignored.</p><p>STOMP clients that wish to be tolerant of late arriving heart-beats from the broker must implement their own solution for doing so.</p><ul><li>Please check the <a shape="rect" class="external-link" href="ht
 tp://stomp.github.io/stomp-specification-1.2.html#Heart-beating" rel="nofollow">STOMP specification</a> for the details on heart-beating</li><li>The JIRA that implemented this: <a shape="rect" class="external-link" href="https://issues.apache.org/jira/browse/AMQ-4674">ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol</a></li></ul><h3 id="Stomp-WorkingwithDestinationswithStomp">Working with Destinations with Stomp</h3><p>Note that the prefix in stomp <strong><code>/queue/</code></strong> or&#160;<strong><code>/topic/</code></strong> is removed from the string before passing it to ActiveMQ as a JMS destination. Also note that the default separator in MOM systems is&#160;<strong><code>.</code></strong> (dot). So <strong><code>FOO.BAR</code></strong> is the normal syntax of a MOM queue - the Stomp equivalent would be <strong><code>/queue/FOO.BAR</code></strong></p><div class="confluence-information-macro confluence-information-
 macro-warning"><p class="title">Be careful about starting destinations with /</p><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>If in Stomp world you use&#160;<strong><code>/queue/foo/bar</code></strong> then in a JMS world the queue would be called <strong><code>foo/bar</code></strong> not&#160;<strong><code>/foo/bar</code></strong>.</p></div></div><h3 id="Stomp-PersistenceofStompmessages">Persistence of Stomp messages</h3><p>By default, Stomp produced messages are set to non-persistent. You have to explicitly tell your Stomp library to add&#160;<strong><code>persistent:true</code></strong> to all&#160;<strong><code>SEND</code></strong> requests, for any messages that you want to persist across ActiveMQ restarts. This is the opposite of the default for JMS submitted messages.</p><h3 id="Stomp-WorkingwithJMSText/BytesMessagesandStomp">Working with JMS Text/Bytes Messages and Stomp</h
 3><p>Stomp is a very simple protocol - that's part of the beauty of it! As such, it does not have knowledge of JMS messages such as&#160;<strong><code>TextMessage</code></strong>'s or <strong><code>BytesMessage</code></strong>'s. The protocol does however support a content-length header. To provide more robust interaction between Stomp and JMS clients, ActiveMQ keys off of the inclusion of this header to determine what message type to create when sending from Stomp to JMS. The logic is simple:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Inclusion of content-length header</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Resulting Message</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>yes</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong><code>BytesMessage</code></strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>no</p></td><td cols
 pan="1" rowspan="1" class="confluenceTd"><p><strong><code>TextMessage</code></strong></p></td></tr></tbody></table></div><p>This same logic can be followed when going from JMS to Stomp, as well. A Stomp client could be written to key off of the inclusion of the content-length header to determine what type of message structure to provide to the user.</p><h3 id="Stomp-Messagetransformations">Message transformations</h3><p>The <strong><code>transformation</code></strong> message header on <strong><code>SEND</code></strong> and <strong><code>SUBSCRIBE</code></strong> messages could be used to instruct ActiveMQ to transform messages from text to the format of your desire. Currently, ActiveMQ comes with a transformer that can transform XML/JSON text to Java objects, but you can add your own transformers as well.</p><p>Here's a quick example of how to use built-in transformer (taken from test cases)</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelCont
 ent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">    private String xmlObject = "&lt;pojo&gt;\n" 
             + "  &lt;name&gt;Dejan&lt;/name&gt;\n"
             + "  &lt;city&gt;Belgrade&lt;/city&gt;\n" 
@@ -133,14 +132,14 @@ uri="stomp://localhost:61613?transport.h
         stompConnection.sendFrame(frame);
     }     
 </pre>
-</div></div><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Dependencies</p><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>ActiveMQ uses <a shape="rect" class="external-link" href="http://xstream.codehaus.org" rel="nofollow">XStream</a> for its transformation needs. Since it's the optional dependency you have to add it to broker's classpath by putting the appropriate JAR into the <code>lib/</code> folder. Additionally, if you plan to use JSON transformations you have to add <a shape="rect" class="external-link" href="http://jettison.codehaus.org/" rel="nofollow">Jettison</a> JSON parser to the classpath.</p></div></div><p>In order to create your own transformer, you have to do the following:</p><ol><li>Build your transformer by implementing a <a shape="rect" class="external-link" href="http://activemq.apache.org/maven/activemq-core/a
 pidocs/org/apache/activemq/transport/stomp/FrameTranslator.html">FrameTranslator</a> interface</li><li>Associate it with the appropriate header value by creating a file named as a value you want to use in the <code>META-INF/services/org/apache/activemq/transport/frametranslator/</code> folder of your JAR which will contain the value <code>class=<em>full classname of your transformer</em></code></li></ol><p>For example the built-in transformer contains the following value</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Dependencies</p><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>ActiveMQ uses <a shape="rect" class="external-link" href="http://xstream.codehaus.org" rel="nofollow">XStream</a> for its transformation needs. Since it's the optional dependency you have to add it to broker's classpath by putting the appropriate JAR into the <strong><code>lib/</code></strong> folder. Additionally, if you plan to use JSON transformations you have to add <a shape="rect" class="external-link" href="http://jettison.codehaus.org/" rel="nofollow">Jettison</a> JSON parser to the classpath.</p></div></div><p>In order to create your own transformer, you have to do the following:</p><ol><li>Build your transformer by implementing a <a shape="rect" class="external-link" href="http://activemq.apache.org/mave
 n/activemq-core/apidocs/org/apache/activemq/transport/stomp/FrameTranslator.html">FrameTranslator</a> interface</li><li>Associate it with the appropriate header value by creating a file named as a value you want to use in the <strong><code>META-INF/services/org/apache/activemq/transport/frametranslator/</code></strong> folder of your JAR which will contain the value <strong><code>class=<em>fully qualified classname of your transformer</em></code></strong></li></ol><p>For example the built-in transformer contains the following value</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">class=org.apache.activemq.transport.stomp.XStreamFrameTranslator</pre>
-</div></div><p>in the <code>META-INF/services/org/apache/activemq/transport/frametranslator/jms-xml</code> file.</p><h3 id="Stomp-Debugging"><span style="line-height: 1.5625;">Debugging</span></h3><p>In case you want to debug Stomp communication between broker and clients you should configure the Stomp connector with the <code>trace</code> parameter, like this:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>in the <strong><code>META-INF/services/org/apache/activemq/transport/frametranslator/jms-xml</code></strong> file.</p><h3 id="Stomp-Debugging"><span style="line-height: 1.5625;">Debugging</span></h3><p>In case you want to debug Stomp communication between broker and clients you should configure the Stomp connector with the <strong><code>trace</code></strong> parameter, like this:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;transportConnectors&gt;
    &lt;transportConnector name="stomp" uri="stomp://localhost:61613?trace=true"/&gt;
 &lt;/transportConnectors&gt;
 </pre>
-</div></div><p>This will instruct the broker to trace all packets it sends and receives.</p><p>Furthermore, you have to enable tracing for the appropriate log. You can achieve that by adding the following to your <code>conf/log4j.properties</code></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>This will instruct the broker to trace all packets it sends and receives.</p><p>Furthermore, you have to enable tracing for the appropriate log. You can achieve that by adding the following to your <strong><code>conf/log4j.properties</code></strong></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">log4j.logger.org.apache.activemq.transport.stomp=TRACE
 </pre>
 </div></div><p>Finally, you will probably want to keep these messages in the separate file instead of polluting the standard broker's log. You can achieve that with the following log4j configuration:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
@@ -155,18 +154,18 @@ log4j.appender.stomp.layout.ConversionPa
 log4j.logger.org.apache.activemq.transport.stomp=TRACE, stomp
 log4j.additivity.org.apache.activemq.transport.stomp=false
 
-# Enable these two lines and disable the above two if you want the
-frame IO ONLY (e.g., no heart beat messages, inactivity monitor etc).
+# Enable these two lines and disable the above two if you want the frame IO ONLY (e.g., no heart beat messages, inactivity monitor etc).
 #log4j.logger.org.apache.activemq.transport.stomp.StompIO=TRACE, stomp
 #log4j.additivity.org.apache.activemq.transport.stomp.StompIO=false
 </pre>
-</div></div><p>After this, all your Stomp packets will be logged to the <code>data/stomp.log</code></p><h3 id="Stomp-JavaAPI">Java API</h3><p>Since version 5.2, there is a simple Java Stomp API distributed with ActiveMQ. Note that this API is provided purely for testing purposes and you should always consider using standard JMS API from Java instead of this one. The following code snippet provides a simple example of using this API:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>After this, all your Stomp packets will be logged to the <strong><code>data/stomp.log</code></strong></p><h3 id="Stomp-JavaAPI">Java API</h3><p>Since version 5.2, there is a simple Java Stomp API distributed with ActiveMQ. Note that this API is provided purely for testing purposes and you should always consider using standard JMS API from Java instead of this one. The following code snippet provides a simple example of using this API:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">StompConnection connection = new StompConnection();
 connection.open("localhost", 61613);
 		
 connection.connect("system", "manager");
 StompFrame connect = connection.receive();
-if (!connect.getAction().equals(Stomp.Responses.CONNECTED)) {
+
+if(!connect.getAction().equals(Stomp.Responses.CONNECTED)) {
 	throw new Exception ("Not connected");
 }
 		
@@ -194,7 +193,7 @@ connection.disconnect();
 </div></div><p>This example is distributed with the ActiveMQ distribution. You can run it from the <code>example</code> folder with</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">ant stomp
 </pre>
-</div></div><h3 id="Stomp-StompextensionsforJMSmessagesemantics">Stomp extensions for JMS message semantics</h3><p>Note that Stomp is designed to be as simple as possible - so any scripting language / platform can message any other with minimal effort.</p><p>Stomp allows pluggable headers on each request such as sending &amp; receiving messages. ActiveMQ has several extensions to the Stomp protocol, so that JMS semantics can be supported by Stomp clients. An OpenWire JMS producer can send messages to a Stomp consumer, and a Stomp producer can send messages to an OpenWire JMS consumer. And Stomp to Stomp configurations, can use the richer JMS message control.</p><p>Stomp supports the following standard JMS properties on SENT messages:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Stomp header</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>JMS header</p></th><th colspan="1" rowspan="1" class="confl
 uenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>correlation-id</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSCorrelationID</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Good consumers will add this header to any responses they send</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>expires</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSExpiration</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Expiration time of the message</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>persistent</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSDeliveryMode</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether or not the message is persistent</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>priority</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSPriority</p></td><td colspan="1" rowspan="1" clas
 s="confluenceTd"><p>Priority on the message</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>reply-to</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSReplyTo</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Destination you should send replies to</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>type</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSType</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Type of the message</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSXGroupID</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSXGroupID</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the <a shape="rect" href="message-groups.html">Message Groups</a></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSXGroupSeq</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>JMSXGroupSeq</p></td><td colspan="1" rowspan="1" cla
 ss="confluenceTd"><p>Optional header that specifies the sequence number in the <a shape="rect" href="message-groups.html">Message Groups</a></p></td></tr></tbody></table></div><h3 id="Stomp-ActiveMQextensionstoStomp">ActiveMQ extensions to Stomp</h3><p>You can add custom headers to Stomp commands to configure the ActiveMQ protocol. Here are some examples:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Verb</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Header</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Type</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>CONNECT</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>client-id</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>string</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JMS Client ID which i
 s used in combination with the activemq.subcriptionName to denote a durable subscriber.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>selector</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>string</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies a JMS Selector using SQL 92 syntax as specified in the JMS 1.1 specificiation. This allows a filter to be applied to each message as part of the subscription.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.dispatchAsync</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>boolean</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Should messages be dispatched synchronously or asynchronously from the producer thread for non-durable topics in the broker? For fast consumers set this to <strong>false</stro
 ng>. For slow consumers set it to <strong>true</strong> so that dispatching will not block fast consumers.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.exclusive</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>boolean</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>I would like to be an <a shape="rect" href="exclusive-consumer.html">Exclusive Consumer</a> on the queue.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.maximumPendingMessageLimit</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>int</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>For <a shape="rect" href="slow-consumer-handling.html">Slow Consumer Handling</a> on non-durable topics by dropping old messages - we can set a maximum-pending limit, such that once a slow consumer b
 acks up to this high water mark we begin to discard old messages.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.noLocal</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>boolean</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether or not locally sent messages should be ignored for subscriptions. Set to <strong>true</strong> to filter out locally sent messages.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.prefetchSize</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>int</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the maximum number of pending messages that will be dispatched to the client. Once this maximum is reached no more messages are dispatched until the client acknowledges a message. Set to a low value &gt
 ; <strong>1</strong> for fair distribution of messages across consumers when processing messages can be slow. STOMP does not support a value of 0.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.priority</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>byte</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Sets the priority of the consumer so that dispatching can be weighted in priority order.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.retroactive</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>boolean</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>For non-durable topics make this subscription <a shape="rect" href="retroactive-consumer.html">retroactive</a>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>SUBSCRIBE<
 /p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>activemq.subscriptionName</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>string</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>For durable topic subscriptions you must specify the same clientId on the connection and subcriptionName on the subscribe <strong>prior to v5.7.0</strong>.<br clear="none" class="atl-forced-newline"> <em><strong>Note the spelling</strong></em>: subcriptionName NOT subscriptionName. This is not intuitive, but it is how it is implemented in ActiveMQ 4.x. For the 5.0 release of ActiveMQ, both subcriptionName and <strong><em>subscriptionName</em></strong> will be supported <strong>(subcriptionName removed as of v5.6.0)</strong></p></td></tr></tbody></table></div></div>
+</div></div><h3 id="Stomp-StompExtensionsforJMSMessageSemantics">Stomp Extensions for JMS Message Semantics</h3><p>Note that STOMP is designed to be as simple as possible - so any scripting language / platform can message any other with minimal effort. STOMP allows pluggable headers on each request such as sending &amp; receiving messages. ActiveMQ has several extensions to the Stomp protocol, so that JMS semantics can be supported by Stomp clients. An OpenWire JMS producer can send messages to a Stomp consumer, and a Stomp producer can send messages to an OpenWire JMS consumer. And Stomp to Stomp configurations, can use the richer JMS message control.</p><p>STOMP supports the following standard JMS properties on&#160;<strong><code>SENT</code></strong> messages:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>STOMP Header</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>JMS Header</p></th><th colspan
 ="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>correlation-id</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSCorrelationID</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Good consumers will add this header to any responses they send.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>expires</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSExpiration</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Expiration time of the message.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>persistent</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSDeliveryMode</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether or not the message is persistent.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>prior
 ity</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSPriority</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Priority on the message.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>reply-to</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSReplyTo</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Destination you should send replies to.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>type</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSType</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Type of the message.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSXGroupID</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSXGroupID</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the <a shape="rect" href="message-groups.ht
 ml">Message Groups.</a></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSXGroupSeq</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>JMSXGroupSeq</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Optional header that specifies the sequence number in the <a shape="rect" href="message-groups.html">Message Groups.</a></p></td></tr></tbody></table></div><h3 id="Stomp-ActiveMQExtensionstoSTOMP">ActiveMQ Extensions to STOMP</h3><p>You can add custom headers to STOMP commands to configure the ActiveMQ protocol. Here are some examples:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Verb</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Header</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Type</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd
 "><p><code>CONNECT</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>client-id</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>string</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JMS clientID which is used in combination with the&#160;<strong><code>activemq.subcriptionName</code></strong> to denote a durable subscriber.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>selector</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>string</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies a JMS Selector using SQL 92 syntax as specified in the JMS 1.1 specification. This allows a filter to be applied to each message as part of the subscription.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colsp
 an="1" rowspan="1" class="confluenceTd"><p><code>activemq.dispatchAsync</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>boolean</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Should messages be dispatched synchronously or asynchronously from the producer thread for non-durable topics in the broker?</p><p>For fast consumers set this to <strong><code>false</code></strong>.</p><p>For slow consumers set it to&#160;<strong><code>true</code></strong> so that dispatching will not block fast consumers.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.exclusive</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>boolean</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>I would like to be an <a shape="rect" href="exclusive-consumer.html">Exclusive Consumer</a> on the queue.</p></td></tr><tr><td 
 colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.maximumPendingMessageLimit</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>int</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>For <a shape="rect" href="slow-consumer-handling.html">Slow Consumer Handling</a> on non-durable topics by dropping old messages - we can set a maximum-pending limit, such that once a slow consumer backs up to this high water mark we begin to discard old messages.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.noLocal</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>boolean</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether or not locally sent messages should be ignored for subscriptions.</p><p>Se
 t to <strong><code>true</code></strong> to filter out locally sent messages.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.prefetchSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>int</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the maximum number of pending messages that will be dispatched to the client. Once this maximum is reached no more messages are dispatched until the client acknowledges a message.</p><p>Set to a low value &gt; <strong>1</strong> for fair distribution of messages across consumers when processing messages can be slow</p><p><strong>Note</strong>: if your STOMP client is implemented using a dynamic scripting language like Ruby, say, then this parameter <strong><em>must</em></strong> be set to&#160;<strong><code>1</code></strong> as there is no notion of a client-side message size to 
 be sized.</p><p>STOMP does not support a value of <strong><code>0</code></strong>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.priority</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>byte</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Sets the priority of the consumer so that dispatching can be weighted in priority order.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.retroactive</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>boolean</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>For non-durable topics make this subscription <a shape="rect" href="retroactive-consumer.html">retroactive</a>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"
 ><p><code>SUBSCRIBE</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>activemq.subscriptionName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>string</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>For durable topic subscriptions you must specify the same&#160;<strong><code>activemq.client-id</code></strong> on the connection and <strong><code>activemq.subcriptionName</code></strong> on the subscribe prior to v5.7.0.</p><p><strong>Note</strong>: the spelling <strong><code>subcriptionName</code></strong> NOT <strong><code>subscriptionName</code></strong>. This is not intuitive, but it is how it is implemented in ActiveMQ 4.x.</p><p>For the 5.0 release of ActiveMQ, both&#160;<strong><code>subcriptionName</code></strong> and&#160;<strong><code>subscriptionName</code></strong> will be supported (<strong><code>subcriptionName</code></strong> was removed as of v5.6.0).</p></td></tr><tr><td colspan="1" rowspan="1" class="c
 onfluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td></tr></tbody></table></div></div>
         </td>
         <td valign="top">
           <div class="navigation">