<div class="wiki-content maincontent"><p>The configuration of ActiveMQ is so slick, we decided to take a similar approach with ActiveMQ-CPP.  All configuration is achieved via URI-encoded parameters, either on the connection or destinations.  Through the URIs, you can configure virtually every facet of your ActiveMQ-CPP client.  The tables below show the comprehensive set of parameters.</p>


<h2><strong>Connection URI Parameters</strong></h2>

<h4>Example Configuration</h4>

<structured-macro ac:macro-id="f8ac92f6-d75e-4a5f-8c13-6ae42fd8a7c3" ac:name="code" ac:schema-version="1"><plain-text-body>
cf = new ActiveMQConnectionFactory(
    "tcp://localhost:61616?wireFormat=openwire&amp;wireFormat.tightEncodingEnabled=true");
</plain-text-body></structured-macro>


<h3><strong>Socket Options</strong></h3>
<table><tbody><tr><th colspan="1" rowspan="1"><p>Option 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>inputBufferSize</p></td><td colspan="1" rowspan="1"><p>10000</p></td><td colspan="1" rowspan="1"><p>The number of bytes in the buffered input stream's buffer</p></td></tr><tr><td colspan="1" rowspan="1"><p>outputBufferSize</p></td><td colspan="1" rowspan="1"><p>10000</p></td><td colspan="1" rowspan="1"><p>The number of bytes in the buffered output stream's buffer</p></td></tr><tr><td colspan="1" rowspan="1"><p>soLinger</p></td><td colspan="1" rowspan="1"><p>0</p></td><td colspan="1" rowspan="1"><p>Socket SOLinger value</p></td></tr><tr><td colspan="1" rowspan="1"><p>soKeepAlive</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Socket SOKeepAlive value</p></td></tr><tr><td colspan="1" rowspan="1"><p>soReceiveBufferSize</p></td><td colspan="1" rowspan="1"><p>-1</p></td><td colspan="1" rowspan="1"><p>Socket receive buffer. If -1, use OS default.</p></td></tr><tr><td colspan="1" rowspan="1"><p>soSendBufferSize</p></td><td colspan="1" rowspan="1"><p>-1</p></td><td colspan="1" rowspan="1"><p>Socket send buffer. If -1, use OS default.</p></td></tr></tbody></table>


<h3><strong>Transport Options</strong></h3>
<table><tbody><tr><th colspan="1" rowspan="1"><p>Option 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>commandTracingEnabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>If true, enables tracing of incoming and outgoing transport commands</p></td></tr><tr><td colspan="1" rowspan="1"><p>tcpTracingEnabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>If true, enables tracing of raw network IO (in hex)</p></td></tr><tr><td colspan="1" rowspan="1"><p>useAsyncSend</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>If true, enables asynchronous sending of messages.</p></td></tr></tbody></table>


<h3><strong>Transaction Options</strong></h3>
<table><tbody><tr><th colspan="1" rowspan="1"><p>Option 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>transaction.maxRedeliveryCount</p></td><td colspan="1" rowspan="1"><p>5</p></td><td colspan="1" rowspan="1"><p>Maximum number of redelivery attempts.</p></td></tr></tbody></table>


<h3><strong>Wire Format Protocol Options</strong></h3>
<table><tbody><tr><th colspan="1" rowspan="1"><p>Option 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>wireFormat</p></td><td colspan="1" rowspan="1"><p>openwire</p></td><td colspan="1" rowspan="1"><p>Selects the wire format to use.  Out of the box, can be either stomp or openwire.</p></td></tr><tr><td colspan="1" rowspan="1"><p>wireFormat.stackTraceEnabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Should the stack trace of exception that occur on the broker be sent to the client?  Only used by openwire protocol.</p></td></tr><tr><td colspan="1" rowspan="1"><p>wireFormat.cacheEnabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Should commonly repeated values be cached so that less marshalling occurs? Only used by openwire protocol.</p></td></tr><tr><td colspan="1" rowspan="1"><p>wireFormat.tcpNoDelayEnabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Does not affect the wire format, but provides a hint to the peer that TCP nodelay should be enabled on the communications Socket. Only used by openwire protocol.</p></td></tr><tr><td colspan="1" rowspan="1"><p>wireFormat.sizePrefixDisabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Should serialized messages include a payload length prefix?  Only used by openwire protocol.</p></td></tr><tr><td colspan="1" rowspan="1"><p>wireFormat.tightEncodingEnabled</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Should wire size be optimized over CPU usage? Only used by the openwire protocol.</p></td></tr></tbody></table>


<h2><strong>Destination URI Parameters</strong></h2>

<h4>Example Configuration</h4>

<structured-macro ac:macro-id="60e75886-3975-4e30-af58-247e9b0a740f" ac:name="code" ac:schema-version="1"><plain-text-body>
d = session-&gt;createTopic("com.foo?consumer.prefetchSize=2000&amp;consumer.noLocal=true");
</plain-text-body></structured-macro>

<h3><strong>General Options</strong></h3>
<table><tbody><tr><th colspan="1" rowspan="1"><p>Option 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>consumer.prefetchSize</p></td><td colspan="1" rowspan="1"><p> 1000 </p></td><td colspan="1" rowspan="1"><p> The number of message the consumer will <link><page ri:content-title="What is the Prefetch Limit For?"></page><link-body>prefetch</link-body></link>.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.maximumPendingMessageLimit</p></td><td colspan="1" rowspan="1"><p> 0 </p></td><td colspan="1" rowspan="1"><p> Use to control if messages are dropped if a <link><page ri:content-title="Slow Consumer Handling"></page><link-body>slow consumer</link-body></link> situation exists.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.noLocal </p></td><td colspan="1" rowspan="1"><p> false </p></td><td colspan="1" rowspan="1"><p> Same as the noLocal flag on a Topic consumer.  Exposed here so that it can be used with a queue.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.dispatchAsync </p></td><td colspan="1" rowspan="1"><p> false </p></td><td colspan="1" rowspan="1"><p> Should the broker <link><page ri:content-title="Consumer Dispatch Async"></page><link-body>dispatch messages asynchronously</link-body></link>  to the consumer.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.retroactive</p></td><td colspan="1" rowspan="1"><p> false</p></td><td colspan="1" rowspan="1"><p> Is this a <link><page ri:content-title="Retroactive Consumer"></page></link>.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.selector</p></td><td colspan="1" rowspan="1"><p> null </p></td><td colspan="1" rowspan="1"><p> JMS Selector used with the consumer.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.exclusive</p></td><td colspan="1" rowspan="1"><p> false </p></td><td colspan="1" rowspan="1"><p> Is this an <link><page ri:content-title="Exclusive Consumer"></page></link>.</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.priority</p></td><td colspan="1" rowspan="1"><p> 0 </p></td><td colspan="1" rowspan="1"><p> Allows you to configure a <link><page ri:content-title="Consumer Priority"></page></link>.</p></td></tr></tbody></table>


<h3><strong>OpenWire-only Options</strong></h3>
<table><tbody><tr><th colspan="1" rowspan="1"><p>Option 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>consumer.browser</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>&#160;</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.networkSubscription</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>&#160;</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.optimizedAcknowledge</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p> Enables an optimised acknowledgement mode where messages are acknowledged in batches rather than individually. Alternatively, you could use Session.DUPS_OK_ACKNOWLEDGE acknowledgement mode for the consumers which can often be faster. <strong>WARNING</strong> enabling this issue could cause some issues with auto-acknowledgement on reconnection</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.noRangeAcks</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>&#160;</p></td></tr><tr><td colspan="1" rowspan="1"><p>consumer.retroactive</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>Sets whether or not retroactive consumers are enabled. Retroactive consumers allow non-durable topic subscribers to receive old messages that were published before the non-durable subscriber started.</p></td></tr><tr><td colspan="1" rowspan="1"><p>producer.dispatchAsyc</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>&#160;</p></td></tr></tbody></table>

</div>