activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1026109 - in /websites/production/activemq/content: cache/main.pageCache networks-of-brokers.html
Date Wed, 28 Feb 2018 16:23:33 GMT
Author: buildbot
Date: Wed Feb 28 16:23:33 2018
New Revision: 1026109

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/networks-of-brokers.html

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

Modified: websites/production/activemq/content/networks-of-brokers.html
==============================================================================
--- websites/production/activemq/content/networks-of-brokers.html (original)
+++ websites/production/activemq/content/networks-of-brokers.html Wed Feb 28 16:23:33 2018
@@ -270,7 +270,7 @@
       </networkConnector>
     </networkConnectors>
 </pre>
-</div></div><p><strong>N.B.</strong> You can only use <a
shape="rect" href="wildcards.html">wildcards</a> in the <code>excludedDestinations</code>
and <code>dynamicallyIncludedDestinations</code> properties.<br clear="none">
<strong>N.B.</strong> <strong>Do not</strong> change the name of the
bridge or the name of the Broker if you are using durable topic subscribers across the network.
Internally ActiveMQ uses the network name and broker name to build a unique but repeatable
durable subscriber name for the network.</p><h3 id="NetworksofBrokers-StuckMessages(version5.6)">Stuck
Messages (version 5.6)</h3><p>By default, it is not permissible for a message
to be replayed back to the broker from which it came. This ensures that messages do not loop
when duplex or by directional network connectors are configured. Occasionally it is desirable
to allow replay for queues. Consider a scenario where a bidirectional bridge exists between
a broker pair. Producers and Consumers get to randomly c
 hoose a broker using the failover transport. If one broker is restarted for maintenance,
messages accumulated on that broker, that crossed the network bridge, will not be available
to consumers till they reconnect to the broker. One solution to this problem is to force a
client reconnect using <a shape="rect" class="external-link" href="http://activemq.apache.org/failover-transport-reference.html#FailoverTransportReference-BrokersideOptionsforFailover">rebalanceClusterClients</a>.
Another, is to allow replay of messages back to the origin as there is no local consumer on
that broker.<br clear="none"> There is a destination policy that allows this behavior
for queues by configuring a <code>conditionalNetworkBridgeFilterFactory</code>
with <code>replayWhenNoConsumers=true</code>. The <code>conditionalNetworkBridgeFilterFactory</code>
provides an optional <code>replayDelay</code> based on the broker-in time.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeCont
 ent panelContent pdl">
+</div></div><p><strong>N.B.</strong> You can only use <a
shape="rect" href="wildcards.html">wildcards</a> in the <code>excludedDestinations</code>
and <code>dynamicallyIncludedDestinations</code> properties.<br clear="none">
<strong>N.B.</strong> <strong>Do not</strong> change the name of the
bridge or the name of the Broker if you are using durable topic subscribers across the network.
Internally ActiveMQ uses the network name and broker name to build a unique but repeatable
durable subscriber name for the network.</p><h3 id="NetworksofBrokers-StuckMessages">Stuck
Messages</h3><p>By default, it is not permissible for a message to be replayed
back to the broker from which it came. This ensures that messages do not loop when duplex
or by directional network connectors are configured. Occasionally it is desirable to allow
replay for queues. Consider a scenario where a bidirectional bridge exists between a broker
pair. Producers and Consumers get to randomly choose a broker using the f
 ailover transport. If one broker is restarted for maintenance, messages accumulated on that
broker, that crossed the network bridge, will not be available to consumers till they reconnect
to the broker. One solution to this problem is to force a client reconnect using <a shape="rect"
class="external-link" href="http://activemq.apache.org/failover-transport-reference.html#FailoverTransportReference-BrokersideOptionsforFailover">rebalanceClusterClients</a>.
Another, is to allow replay of messages back to the origin as there is no local consumer on
that broker. From version 5.16.0, using <code>selectorAware=true</code> the replay
can occur if there are no local consumers who's selectors match the target message.<br
clear="none"> There is a destination policy that allows this behavior for queues by configuring
a <code>conditionalNetworkBridgeFilterFactory</code> with <code>replayWhenNoConsumers=true</code>.
The <code>conditionalNetworkBridgeFilterFactory</code> provides an optional <cod
 e>replayDelay</code> based on the broker-in time.</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;destinationPolicy&gt;
       &lt;policyMap&gt;
         &lt;policyEntries&gt;



Mime
View raw message