[CONF] Apache ActiveMQ > Networks of Brokers

2019-01-21 Thread Christopher L. Shannon (Confluence)
Title: Message Title



 
 
 
There's 1 new edit on this page 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Christopher L. Shannon edited this page 
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Here's what changed: 
 
 
 
 
 
 
 
 
 
 
 ... 
 
 
 
 
 
 
 
 
 
 property  
 default  
 description  
 
 
 name  
 bridge  
 name of the network - for more than one network connector between the same two brokers - use different names  
 
 
 dynamicOnly  
 false  
 if true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup.  
 
 
 decreaseNetworkConsumerPriority  
 false  
 if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers  
 
 
 networkTTL  
 1  
 the number of brokers in the network that messages and subscriptions can pass through (sets both message&consumer -TTL)  
 
 
 messageTTL  
 1  
 (version 5.9) the number of brokers in the network that messages can pass through  
 
 
 consumerTTL  
 1  
 (version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh)  
 
 
 conduitSubscriptions  
 true  
 multiple consumers subscribing to the same destination are treated as one consumer by the network  
 
 
 excludedDestinations  
 empty  
 destinations matching this list won't be forwarded across the network (this only applies to dynamicallyIncludedDestinations)   
 
 
 dynamicallyIncludedDestinations  
 empty  
 
 
 destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the   
  exluded  
 
 excluded list will be forwarded. Starting with version 5.14.0 the flag forceDurable can be appended to a topic which will ensure the subscription between the two brokers is always a durable subscription. See   
 
 
 
 Jira 
 
 
 
 
 
 
 
 
server 
ASF JIRA 
 
 
columns 
key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution 
 
 
serverId 
5aa69414-a9e9-3523-82ec-879b028fb15b 
 
 
key 
AMQ-6383 
 
 
  
 
 
 
 
  
 
 
 useVirtualDestSubs  
 false  
 if true, the network connection will listen to advisory messages for virtual destination consumers  
 
 
 staticallyIncludedDestinations  
 empty  
 
 
 destinations that match will always be passed across the network - even if no consumers have ever registered an interest. Starting with version 5.14.0 the flag forceDurable can be appended to a topic which will ensure the subscription between the two brokers is always a durable subscription. See   
 
 
 
 Jira 
 
 
 
 
 
 
 
 
server 
ASF JIRA 
 
 
columns 
key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution 
 
 
serverId 
5aa69414-a9e9-3523-82ec-879b028fb15b 
 
 
key 
AMQ-6383 
 
 
  
 
 
 
 
  
 
 
 duplex  
 false  
 if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.  
 
 
 prefetchSize  
 1000  
 Sets the prefetch size on the network connector's consumer. It must be > 0 because network consumers do not poll for messages  
 
 
 suppressDuplicateQueueSubscriptions  
 false  
 (from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.  
 
 
 bridgeTempDestinations  
 true  
 Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request-reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of broke

[CONF] Apache ActiveMQ > Networks of Brokers

2018-02-28 Thread Gary Tully (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Gary Tully edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
Change comment: selectorAware attribute in 5.16 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ...  N.B. You can only use wildcards in the excludedDestinations and dynamicallyIncludedDestinations properties. N.B. Do not 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.  Stuck Messages  ...  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 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 rebalanceClusterClients. 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 selectorAware=true the replay can occur if there are no local consumers who's selectors match the target message.  There is a destination policy that allows this behavior for queues by configuring a conditionalNetworkBridgeFilterFactory with replayWhenNoConsumers=true. The conditionalNetworkBridgeFilterFactory provides an optional replayDelay based on the broker-in time. ...  
 
 
  
 
 
 
 
 
 
 
 
 
 

View page
• 
 
 
 
 
 
 

Like 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 5.8.17  
 
 
  
 
 
 
 
 
 
 
 
 




[CONF] Apache ActiveMQ > Networks of Brokers

2016-08-25 Thread Matt Pavlovich (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Matt Pavlovich edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
Change comment: Added userName and password options to the list of attributes 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... 
 
 
 
 
 property  
 default  
 description  
 
 
 name  
 bridge  
 name of the network - for more than one network connector between the same two brokers - use different names  
 
 
 dynamicOnly  
 false  
 if true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup.  
 
 
 decreaseNetworkConsumerPriority  
 false  
 if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers  
 
 
 networkTTL  
 1  
 the number of brokers in the network that messages and subscriptions can pass through (sets both message&consumer -TTL)  
 
 
 messageTTL  
 1  
 (version 5.9) the number of brokers in the network that messages can pass through  
 
 
 consumerTTL  
 1  
 (version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh)  
 
 
 conduitSubscriptions  
 true  
 multiple consumers subscribing to the same destination are treated as one consumer by the network  
 
 
 excludedDestinations  
 empty  
 destinations matching this list won't be forwarded across the network (this only applies to dynamicallyIncludedDestinations)   
 
 
 dynamicallyIncludedDestinations  
 empty  
 destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the exluded list will be forwarded  
 
 
 useVirtualDestSubs  
 false  
 if true, the network connection will listen to advisory messages for virtual destination consumers  
 
 
 staticallyIncludedDestinations  
 empty  
 destinations that match will always be passed across the network - even if no consumers have ever registered an interest  
 
 
 duplex  
 false  
 if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.  
 
 
 prefetchSize  
 1000  
 Sets the prefetch size on the network connector's consumer. It must be > 0 because network consumers do not poll for messages  
 
 
 suppressDuplicateQueueSubscriptions  
 false  
 (from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.  
 
 
 bridgeTempDestinations  
 true  
 Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request-reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of brokers).  When disabling this feature such network traffic can be reduced but then producer and consumers of a request-reply message need to be connected to the same broker. Remote consumers (i.e. connected via another broker in your network) won't be able to send the reply message but instead raise a "temp destination does not exist" exception.  
 
 
 alwaysSyncSend  
 false  
 (version 5.6) When true, non persistent messages are sent to the remote broker using request/reply in place of a oneway. This setting treats both persistent and non-persistent messages the same.  
 
 
 staticBridge  
 false  
 (version 5.6) If set to true, broker will not dynamically respond to new consumers. It will only use staticallyIncludedDestinations to create demand subscriptions  
 
 
userName 
null 
The username to authenticate against the remote broker 
 
 
password 
null 
The password for the username to authenticate against the remot

[CONF] Apache ActiveMQ > Networks of Brokers

2016-02-11 Thread Brian D. Johnson (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Brian D. Johnson edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... 
 
 
 
 
 property  
 default  
 description  
 
 
 name  
 bridge  
 name of the network - for more than one network connector between the same two brokers - use different names  
 
 
 dynamicOnly  
 false  
 if true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup.  
 
 
 decreaseNetworkConsumerPriority  
 false  
 if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers  
 
 
 networkTTL  
 1  
 the number of brokers in the network that messages and subscriptions can pass through (sets both message&consumer -TTL)  
 
 
 messageTTL  
 1  
 (version 5.9) the number of brokers in the network that messages can pass through  
 
 
 consumerTTL  
 1  
 (version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh)  
 
 
 conduitSubscriptions  
 true  
 multiple consumers subscribing to the same destination are treated as one consumer by the network  
 
 
 excludedDestinations  
 empty  
 destinations matching this list won't be forwarded across the network (this only applies to dynamicallyIncludedDestinations)   
 
 
 dynamicallyIncludedDestinations  
 empty  
 destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the exluded list will be forwarded  
 
 
  useVirtualDestSubs   
  false   
  if true, the network connection will listen to advisory messages for virtual destination consumers   
 
 
 staticallyIncludedDestinations  
 empty  
 destinations that match will always be passed across the network - even if no consumers have ever registered an interest  
 
 
 duplex  
 false  
 if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.  
 
 
 prefetchSize  
 1000  
 Sets the prefetch size on the network connector's consumer. It must be > 0 because network consumers do not poll for messages  
 
 
 suppressDuplicateQueueSubscriptions  
 false  
 (from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.  
 
 
 bridgeTempDestinations  
 true  
 Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request-reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of brokers).  When disabling this feature such network traffic can be reduced but then producer and consumers of a request-reply message need to be connected to the same broker. Remote consumers (i.e. connected via another broker in your network) won't be able to send the reply message but instead raise a "temp destination does not exist" exception.  
 
 
 alwaysSyncSend  
 false  
 (version 5.6) When true, non persistent messages are sent to the remote broker using request/reply in place of a oneway. This setting treats both persistent and non-persistent messages the same.  
 
 
 staticBridge  
 false  
 (version 5.6) If set to true, broker will not dynamically respond to new consumers. It will only use staticallyIncludedDestinations to create demand subscriptions  
 
 
 
 ...  
 
 
  
 
 
 
 
 
 
 
 
 
 

View page
• 
 
 
 
 
 
 

Like 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluenc

[CONF] Apache ActiveMQ > Networks of Brokers

2016-01-13 Thread Dejan Bosanac (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Dejan Bosanac edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... 
 
 
 
 
 property  
 default  
 description  
 
 
 name  
 bridge  
 name of the network - for more than one network connector between the same two brokers - use different names  
 
 
 dynamicOnly  
 false  
 if true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup.  
 
 
 decreaseNetworkConsumerPriority  
 false  
 if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers  
 
 
 networkTTL  
 1  
 the number of brokers in the network that messages and subscriptions can pass through (sets both message&consumer -TTL)  
 
 
 messageTTL  
 1  
 (version 5.9) the number of brokers in the network that messages can pass through  
 
 
 consumerTTL  
 1  
 (version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh)  
 
 
 conduitSubscriptions  
 true  
 multiple consumers subscribing to the same destination are treated as one consumer by the network  
 
 
 excludedDestinations  
 empty  
 destinations matching this list won't be forwarded across the network (this only applies to dynamicallyIncludedDestinations)   
 
 
 dynamicallyIncludedDestinations  
 empty  
 destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the exluded list will be forwarded  
 
 
useVirtualDestSubs 
false 
if true, the network connection will listen to advisory messages for virtual destination consumers 
 
 
 staticallyIncludedDestinations  
 empty  
 destinations that match will always be passed across the network - even if no consumers have ever registered an interest  
 
 
 duplex  
 false  
 if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.  
 
 
 prefetchSize  
 1000  
 Sets the prefetch size on the network connector's consumer. It must be > 0 because network consumers do not poll for messages  
 
 
 suppressDuplicateQueueSubscriptions  
 false  
 (from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.  
 
 
 bridgeTempDestinations  
 true  
 Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request-reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of brokers).  When disabling this feature such network traffic can be reduced but then producer and consumers of a request-reply message need to be connected to the same broker. Remote consumers (i.e. connected via another broker in your network) won't be able to send the reply message but instead raise a "temp destination does not exist" exception.  
 
 
 alwaysSyncSend  
 false  
 (version 5.6) When true, non persistent messages are sent to the remote broker using request/reply in place of a oneway. This setting treats both persistent and non-persistent messages the same.  
 
 
 staticBridge  
 false  
 (version 5.6) If set to true, broker will not dynamically respond to new consumers. It will only use staticallyIncludedDestinations to create demand subscriptions  
 
 
 
 ... 
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
 
xml 
 
 
 
xml 
 
 
  
 
 
 
 
 
  
  	
  		
  		
  	
  	
  		
  		
  	

  		
  		
  	
  

  
 
 
  Note that at the moment excludedDestinations proper

[CONF] Apache ActiveMQ > Networks of Brokers

2015-12-09 Thread Jakub Korab (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Jakub Korab edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
Change comment: Cleared up description of "Dynamic networks and Virtual Destinations" to make it more understandable. Added formatting to config properties for easier readability. 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... However - duplicate subscriptions is a useful feature to exploit if you are only using Queues. As the load balancing algorithm will attempt to share message load evenly, consumers across a network will equally share the message load only if the flag conduitSubscriptions=false. Here's an example. Suppose you have two brokers, A and B, that are connected to one another via a forwarding bridge. Connected to broker A, you have a consumer that subscribes to a queue called Q.TEST. Connected to broker B, you have two consumers that also subscribe to Q.TEST. All consumers have equal priority. Then you start a producer on broker A that writes 30 messages to Q.TEST. By default, (conduitSubscriptions=true), 15 messages will be sent to the consumer on broker A and the resulting 15 messages will be sent to the two consumers on broker B. The message load has not been equally spread across all three consumers because, by default, broker A views the two subscriptions on broker B as one. If you had set conduitSubscriptions to " to false", then each of the three consumers would have been given 10 messages. ... By default a network bridge forwards messages on demand in one direction over a single connection. When dupex duplex=true, the same connection is used for a network bridge in the opposite directions, resulting in a by bi-directional bridge. The network bridge configuration is propagated to the other broker so the duplex bridge is an exact replica or the original.   Given two brokers, broker A and broker B, a duplex bridge on A to B is the same as a default bridge on A to B and a default bridge on B to A.   Note, if you want to configure more than one duplex network bridge between two brokers, to increase throughput or to partition topics and queues, you must provide unique names for each: eg:  
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
 
xml 
 
 
 
xml 
 
 
  
 
 
 
 
 











 
 
 ... 
 
 
 
 Warning 
 
 
 
 
 Networks do not work as expected (they cannot dynamically respond to new consumers) if the advisorySupport broker property is disabled. A fully statically configured network is the only option if advisorySupport is disabled. Read more about it in the following section.   
 
 
 Networks of brokers and advisories ... 
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
 
xml 
 
 
 
xml 
 
 
  
 
 
 
 
 
  


  
  
 
 
 In earlier versions of ActiveMQ prior to 5.6, the broker would still use the same advisory filter and express interest in all consumers on the remote broker. The actual filtering will be done during message dispatch. This is suboptimal solution in huge networks as it creates a lot of "advisory" traffic and load on the brokers. Starting with version 5.6, the broker will automatically create an appropriate advisory filter and express interest only in dynamically included destinations. For our example it will be "ActiveMQ.Advisory.Consumer.Queue.include.test.foo,ActiveMQ.Advisory.Consumer.Topic.include.test.bar". This can dramatically improve behavior of the network in complex and high-load environments.  So what's to be done in older versions of the broker? Luckily, In older broker versions we can achieve the same thing with a bit slightly more complicated configuration. The actual advisory filter that controls in which consumers we are interested is defined with the destinationFilter connector property. It's Its default value is ">", which is concatenated to the "ActiveMQ.Advisory.Consumer." prefix. So to achieve the same thing, we would need to do the following:  
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
 
xml 
 
 
 
xml 
 
 
  
 
 
 
 
 
  


  
  
 
 
 Note that first destination doesn't does not have the prefix because it's already implied. It's a bit more complicated to set and maintain, but it will work. And if you're using 5.6 or newer version of the broker just including desired destinations with dynamicallyIncludedDestinations should suffice. This also explains why dynamic networks doesn't do not work if you turn off advisory support on the brokers. The brokers in this case cannot dynamically respond to new consumers. ... The staticBridge parameter is available since version 5.6 and it means that the local broker will not subscribe to any advisory topic topics on the remote broker, meaning it is not interested in whether there are any consumers there. Additionally, you need to add a list of destinations to staticallyIncludedDestinations. This will have the same effect as having an additional consume

[CONF] Apache ActiveMQ > Networks of Brokers

2015-12-03 Thread Christopher L. Shannon (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Christopher L. Shannon edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... If configured like this, broker will try to listen for new consumers on ActiveMQ.Advisory.Consumer.NO_DESTINATION, which will never have messages so it will be protected from information on remote broker consumers.  
 
 
 
 Anchor 
 
 
 
 
 
 
 
 
 
virtualconsumers 
 
 
 
virtualconsumers 
 
 
  
 
 
 Dynamic networks and Virtual Destinations (New for 5.13.0)  As described above, a network of brokers can be configured to only send messages to a remote broker when there's a consumer on an included destination.  However, let's consider some cases of how dynamic flow occurs when Virtual Destinations are in use. ...  
 
 
  
 
 
 
 
 
 
 
 
 
 

View page
• 
 
 
 
 
 
 

Like 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 5.8.4  
 
 
  
 
 
 
 
 
 
 
 
 




[CONF] Apache ActiveMQ > Networks of Brokers

2015-11-10 Thread Christopher L. Shannon (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Christopher L. Shannon edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... Here is an example of two brokers networked together.  The local broker contains the network connector configured with a dynamicallyIncludedDestination and the remote broker is configured with a CompositeTopic: 
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Local Broker 
 
 
  
 
 
 
 
 
  	
	
  	
  
 
 
 
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Remote Broker 
 
 
  
 
 
 
 
 



  
 
 
 ... First, we need to configure the broker to send advisory messages when consumers come online onto a destination that matches a Virtual Destination.  In this case, a match is determined by the use of a Destination Filter will determines if a a destination forwards to another destination.  The configuration on the remote broker should be updated to set the property useVirtualDestSubs to true to enable this.     
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Remote Broker 
 
 
  
 
 
 
 
 




 .
  


  
 
 
  Second, we need to configure the network connector to listen for the new advisory messages:     
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Local Broker 
 
 
  
 
 
 
 
 
  

  
  
 
 
 ... Now let's consider the use case above where there is the same composite topic but no consumers on the queue.  
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Remote Broker 
 
 
  
 
 
 
 
 



  
 
 
 There is a composite Topic configured on the remote broker and the local broker is networked to it.  Even though we've enabled useVirtualDestSubs, messages wouldn't be forwarded to the remote broker unless a consumer comes online to the forwarded queue.  This would cause messages to be dropped since they are sent to a topic.  Sometimes it is desirable to have these messages forwarded based on the existence of the virtual destination.  This only applies in the Queue case. For topics, messages should only be forwarded if there is a consumer or durable subscription.     
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Local Broker 
 
 
  
 
 
 
 
 




 .
  



  
 
 
 With this configuration, when the Queue include.test.bar.forward is created, a Virtual Destination consumer advisory will be sent to the local broker so that it knows to forward messages based on the existence of the CompositeTopic and Queue existing. ... The above examples show how to configure a Composite destination but a Virtual Topic will also work.  In the example below, a consumer on a Queue for a Virtual Topic will now cause demand and messages will be sent across a network.   
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Local Broker 
 
 
  
 
 
 
 
 
  

  
  
 
 
 
 
 
 
 Code Block 
 
 
 
 
 
 
 
 
language 
xml 
 
 
title 
Remote Broker 
 
 
  
 
 
 
 
 




 .
  

  
 
 
 ...  
 
 
  
 
 
 
 
 
 
 
 
 
 

View page
• 
 
 
 
 
 
 

Like 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 5.8.4  
 
 
  
 
 
 
 
 
 
 
 
 




[CONF] Apache ActiveMQ > Networks of Brokers

2015-11-10 Thread Christopher L. Shannon (Confluence)
Title: Message Title



 
 
 
 
 
 
 

Christopher L. Shannon edited a page 
 
 
  
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Networks of Brokers 
 
 
  
 
 
 
 
 
 
 ... 
 
 
 
 
 property  
 default  
 description  
 
 
 name  
 bridge  
 name of the network - for more than one network connector between the same two brokers - use different names  
 
 
 dynamicOnly  
 false  
 if true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup.  
 
 
 decreaseNetworkConsumerPriority  
 false  
 if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers  
 
 
 networkTTL  
 1  
 the number of brokers in the network that messages and subscriptions can pass through (sets both message&consumer -TTL)  
 
 
 messageTTL  
 1  
 (version 5.9) the number of brokers in the network that messages can pass through  
 
 
 consumerTTL  
 1  
 (version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh)  
 
 
 conduitSubscriptions  
 true  
 multiple consumers subscribing to the same destination are treated as one consumer by the network  
 
 
 excludedDestinations  
 empty  
 destinations matching this list won't be forwarded across the network  
 
 
 dynamicallyIncludedDestinations  
 empty  
 destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the exluded list will be forwarded  
 
 
useVirtualDestSubs 
false 
if true, the network connection will listen to advisory messages for virtual destination consumers 
 
 
 staticallyIncludedDestinations  
 empty  
 destinations that match will always be passed across the network - even if no consumers have ever registered an interest  
 
 
 duplex  
 false  
 if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.  
 
 
 prefetchSize  
 1000  
 Sets the prefetch size on the network connector's consumer. It must be > 0 because network consumers do not poll for messages  
 
 
 suppressDuplicateQueueSubscriptions  
 false  
 (from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.  
 
 
 bridgeTempDestinations  
 true  
 Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request-reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of brokers).  When disabling this feature such network traffic can be reduced but then producer and consumers of a request-reply message need to be connected to the same broker. Remote consumers (i.e. connected via another broker in your network) won't be able to send the reply message but instead raise a "temp destination does not exist" exception.  
 
 
 alwaysSyncSend  
 false  
 (version 5.6) When true, non persistent messages are sent to the remote broker using request/reply in place of a oneway. This setting treats both persistent and non-persistent messages the same.  
 
 
 staticBridge  
 false  
 (version 5.6) If set to true, broker will not dynamically respond to new consumers. It will only use staticallyIncludedDestinations to create demand subscriptions  
 
 
 
 ... If configured like this, broker will try to listen for new consumers on ActiveMQ.Advisory.Consumer.NO_DESTINATION, which will never have messages so it will be protected from information on remote broker consumers.  Dynamic networks and Virtual Destinations (New for 5.13.0)   As described above, a n

[CONF] Apache ActiveMQ > Networks of Brokers

2014-08-13 Thread Torsten Mielke (Confluence)














  


Torsten Mielke edited the page:
 


Networks of Brokers   




 Comment: example config for replayWhenNoConsumers needs to be wrapped by  


...



 Code Block









xml


 




 
  

  

  replayWhenNoConsumers="true"/>
networkBridgeFilterFactory>
  policyEntry>

  
 



...






 View Online  · Like  · View Changes  
 Stop watching space  · Manage Notifications  


 


 


  This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software