fanout-transport-reference.xml

<div class="wiki-content maincontent"><h3>The Fanout Transport</h3>

<p>The Fanout transport layers reconnect and replication logic on top of any of the other transports. It utilizes the <link><page ri:content-title="Discovery Transport Reference"></page><link-body>Discovery</link-body></link> transport to discover brokers and replicates commands to those brokers.</p>

<h4>Configuration Syntax</h4>

<p><strong>fanout:(discoveryURI)?transportOptions</strong><br clear="none">
or<br clear="none">
<strong>fanout:discoveryURI</strong></p>

<h5>Transport Options</h5>

<table><tbody><tr><th colspan="1" rowspan="1"><p>Option Name</p></th><th colspan="1" rowspan="1"><p>Default Value</p></th><th colspan="1" rowspan="1"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1"><p>initialReconnectDelay</p></td><td colspan="1" rowspan="1"><p>10</p></td><td colspan="1" rowspan="1"><p>How long to wait before the first reconnect attempt</p></td></tr><tr><td colspan="1" rowspan="1"><p>maxReconnectDelay</p></td><td colspan="1" rowspan="1"><p>30000</p></td><td colspan="1" rowspan="1"><p>The maximum amount of time we ever wait between reconnect attempts</p></td></tr><tr><td colspan="1" rowspan="1"><p>useExponentialBackOff</p></td><td colspan="1" rowspan="1"><p>true</p></td><td colspan="1" rowspan="1"><p>Should an exponential backoff be used btween reconnect attempts</p></td></tr><tr><td colspan="1" rowspan="1"><p>backOffMultiplier</p></td><td colspan="1" rowspan="1"><p>2</p></td><td colspan="1" rowspan="1"><p>The exponent used in the exponential backoff attempts</p></td></tr><tr><td colspan="1" rowspan="1"><p>maxReconnectAttempts</p></td><td colspan="1" rowspan="1"><p>0</p></td><td colspan="1" rowspan="1"><p>If not 0, then this is the maximum number of reconnect attempts before an error is sent back to the client</p></td></tr><tr><td colspan="1" rowspan="1"><p>fanOutQueues</p></td><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>If set to 'true', commands are replicated to queues as well as topics</p></td></tr><tr><td colspan="1" rowspan="1"><p>minAckCount</p></td><td colspan="1" rowspan="1"><p>2</p></td><td colspan="1" rowspan="1"><p>The minimum number of brokers to which connections must be established</p></td></tr></tbody></table>



<p>The 'fanOutQueues' option is specific to the fanout transport. By default, the fanout does not replicate commands to queues; only topics. Therefore, if you'd like to fanout a message send command to multiple queues on multiple brokers, you'll have to set this option to 'true'.</p>

<p>By default, a client's fanout transport waits for connections to be established to 2 brokers, or the number of static TCP URIs configured (if more than 2). Until this number of connections is established, the client's call to Connection.createSession() does not return. For example, a producer that uses the fanout connector listed below will wait until 2 brokers are running, and connections are established to those two brokers. </p>
<structured-macro ac:macro-id="14dfe3e4-da24-4f67-ae01-1c3435c1ada2" ac:name="code" ac:schema-version="1"><plain-text-body>
fanout:(multicast://default)
</plain-text-body></structured-macro>
<p>Another example would be a producer using the following fanout connector. </p>
<structured-macro ac:macro-id="6ab706dc-d1f3-409b-a0cc-e7dd193f7f09" ac:name="code" ac:schema-version="1"><plain-text-body>
fanout:(static:(tcp://localhost:61629,tcp://localhost:61639,tcp://localhost:61649))
</plain-text-body></structured-macro>
<p>In this case, three broker connections are needed. However, this required number of connections can be overridden by using the minAckCount transport option. For example, this fanout connector allows the producer to run after connecting to just one broker.</p>
<structured-macro ac:macro-id="015aa0e2-b6a4-445d-ba33-ebad5395e4be" ac:name="code" ac:schema-version="1"><plain-text-body>
fanout:(multicast://default)?minAckCount=1
</plain-text-body></structured-macro>

<structured-macro ac:macro-id="151fccae-78c3-4ec7-a133-2f736fa215f4" ac:name="warning" ac:schema-version="1"><parameter ac:name="title">Warning</parameter><rich-text-body>
<p>It is not recommended that you use the fanout URI for consumers. Also, if a producer fans out across multiple brokers, who happen to be inter-connected, then there is a very high likelihood that a consumer on one of those brokers will get duplicate messages.</p></rich-text-body></structured-macro>


<h5>Example URI</h5>

<structured-macro ac:macro-id="93ce1f99-ce3f-4d11-8d29-062d4c587a36" ac:name="noformat" ac:schema-version="1"><plain-text-body>
fanout:(static:(tcp://localhost:61616,tcp://remotehost:61616))?initialReconnectDelay=100
</plain-text-body></structured-macro>

<structured-macro ac:macro-id="aa78e70d-2f24-413a-97b1-54cf7ebb24a8" ac:name="info" ac:schema-version="1"><parameter ac:name="title">Applying parameters to discovered transports</parameter><rich-text-body>
<p>Because the Discovery transport is utilized for broker discovery, transport parameters are applied to discovered brokers.  See <link><page ri:content-title="Discovery Transport Reference"></page></link>.</p></rich-text-body></structured-macro></div>