In any mesh network, I'd always recommend setting decreaseNetworkConsumerPriority=true. If you do that, and if clients will only ever connect to a single broker, then a networkTTL of 2 is fine, because the message will always traverse at most two brokers.
However, if your consumers can disconnect and reconnect to different brokers in the mesh (e.g. via a failover URL), then it's possible in a pathologically bad scenario for the messages to chase the consumer around the network as it connects to and immediately disconnects from the various brokers in the network, all the while increasing the networkTTL. Again, this is in the pathologically bad case, where the consumer disconnects without doing any work and then connects to a different broker, causing messages flow to that next broker but the consumer then disconnects without consuming any of them. In a more normal scenario, message will have to make at most a few hops before finally getting consumed, so I'd suggest a networkTTL that's higher than 2; a value like 5 is probably safe in most cases, but you could use 10, or 100, if you wanted to be even safer. The more important setting in that case, though, is the replayWhenNoConsumers setting described in the Stuck Messages section at the bottom of http://activemq.apache.org/networks-of-brokers.html. Because if a message is produced on A and the consumer is on C, and the message is routed to C but the consumer disconnects before it can be consumed and then reconnects to A, the default configuration will prevent the message from going back to A and therefore the message will be "lost" (until a consumer connects to C or to B). That's a far more likely scenario than the one that would cause a networkTTL of 5/10/100 to be hit, and the replayWhenNoConsumers attribute allows you to address that situation. Tim Tim On Thu, Feb 8, 2018 at 9:13 AM, Rajesh Malla <mallara...@gmail.com> wrote: > We are using n/w connectors between 3 brokers > is > A->B > A->C > > B->A > B->C > > C->A > C->B > > also we are using synchronous request and reply pattern using camel to send > and receive message in temp queue. > we have question is it good to use networkTTL = 2 in above configuration ? > will it work properly or > is there any chance of losing message ? > for example > > A B C > tmpQ tmpQ tmpQ > > what if producer send message to A and waiting on tmpQ, consumer C receives > message and reply to tmpQ [ of C], ? > > A,B,C are producers and consumers on tmpQ > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
