what value of networkTTL need to use for synchronous request and reply in network connectors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

what value of networkTTL need to use for synchronous request and reply in network connectors

Rajesh Malla
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
Reply | Threaded
Open this post in threaded view
|

Re: what value of networkTTL need to use for synchronous request and reply in network connectors

Tim Bain
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: what value of networkTTL need to use for synchronous request and reply in network connectors

gtully
In reply to this post by Rajesh Malla
In the event of connection failures there is a good chance of loosing
messages.
If you are about messages and replies then use real queues, maybe have a
reply queue per process or per application and use selectors based on the
correlation id if you need to multiplex.

The lifetime of a temp queue is tied to the connection that created it or
to the bridge that forwards, in the event of failure and recovery the temp
goes away for some time. Errors are inevitable and there is the potential
for loss.
There was a bunch of work to ensure all errors were reported but it is not
a good plan if you care about reply messages.

see: RequestReplyTempDestRemovalAdvisoryRaceTest for an example test
scenario in the unit tests.

On Thu, 8 Feb 2018 at 16:38 Rajesh Malla <[hidden email]> 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
>