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.
On Thu, Feb 8, 2018 at 9:13 AM, Rajesh Malla <mallara...@gmail.com> wrote:
> We are using n/w connectors between 3 brokers
> 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-