[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regular and intermittent interrupt/resume between broker and client connector

My recommendation is to use the Failover transport and the
TransportListener interface.

To use the failover transport, just use the following syntax for the broker


For example, with a broker at localhost:61616,
failover://(tcp://localhost:61616), will do the job.

And the transport listener can be used to determine when the connection is
active or disconnected:

Using the "transportInterrupted" and "transportResumed" methods to detect
disconnects and connects.  And use the built-in logging from the failover
transport for diagnostics.

With this setup, the failover transport will make sure messages are sent to
the broker across any number or disconnects and reconnects.  Producers
simply block on "send()" calls until the message is successfully delivered
(unless extra effort is taken to use async delivery).  Likewise, consumers
will keep reconnecting to the broker and attempting to send message
acknowledgements across lost connections.

With all that said, unreliable networks are devastating for network-heavy
applications, and messaging is all about networking.  I highly recommend
having folks look at stabilizing the network as much as possible.

And keep in mind that the way JMS works, for persistent messages on a
queue, you will get message redelivery at times with this setup.  It's not
possible to completely avoid it.


On Wed, May 30, 2018 at 4:12 AM, gerardl <ger.lawlor@xxxxxxxxx> wrote:

> Hi,
> I have implemented client producer to ActiveMQ broker but find with
> firewalls in our environment that there can be regular interrupt/resume
> cycles between the broker and connector. In the connector, when we get a
> resume we set a boolean isConnected and check this when we go to send a
> request to the broker. What I have noticed is that we dequeue the message
> for sending and try to send to find out we are currently disconnected from
> the broker. So our message gets discarded at the client and we report a
> send
> failure. This is not reliable enough for the application setting. Can you
> please offer advice or experience based on similar environment where
> interrupt/resume cycle is regular and how you would guarantee delivery to
> the broker? In my mind, we can enqueue a failed send in the connector again
> until the broker connectivity resumes but I'm concerned that the connector
> would have to handle constant dequeue/enqueue cycle.
> Thanks,
> Ger.
> --
> Sent from:
> f2368404.html