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 <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 >
