Proper handling of disconnected consumers - best approach

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

Proper handling of disconnected consumers - best approach

romanhawk
This post was updated on .
Dear colleagues,

I have the following scenario to implement and looking for best ways to accomplish it:

1. I have embedded broker on the server
2. There are several consumers running behind firewalls/NAT connected to that server
3. Messages are produced by the server and put into the embedded broker to be consumed by remote consumers
4. Communication is based on Queues so only one consumer should receive and handle the message

There are messages, which can be processed by any consumer (some kind of clustering). If some consumer is gracefully turned off, messages are sent to remained consumers without any issue. But what if cable is simply unplugged and consumer is not reachable anymore. Still, as far as I understand, broker put the messages to be consumed by that "dead" consumer so eventually they would not be processed and end up in DLQ. Of course, after timeout, consumer will become disconnected as ActiveMQ will be aware of broken transport, but remaining messages would not be delivered to other consumers.

What is the best approach to deal with such situation (messages put to "dead" consumer to be handled by another consumer). Message redelivery? Probably there is some simpler approach and I'm simply missing some XML configuration for such stuff. Though, as my broker is embedded, I can create any "hooks" to provide necessary functionality if necessary.

PS. Will prefetch equal to 0 help in this situation?
Reply | Threaded
Open this post in threaded view
|

Re:Proper handling of disconnected consumers - best approach

DepestBlue

Do you have any transaction in application? According my experience, the messages should be rolled back to the queue once consumer down in incident.




At 2011-12-06 03:48:17,romanhawk <[hidden email]> wrote:

>Dear colleagues,
>
>I have the following scenario to implement and looking for best ways to
>accomplish it:
>
>1. I have embedded broker on the server
>2. There are several consumers running behind firewalls/NAT connected to
>that server
>3. Messages are produced by the server and put into the embedded broker to
>be consumed by remote consumers
>4. Communication is based on Queues so only one consumer should receive and
>handle the message
>
>There are messages, which can be processed by any consumer (some kind of
>clustering). If some consumer is gracefully turned off, messages are sent to
>remained consumers without any issue. But what if cable is simply unplugged
>and consumer is not reachable anymore. Still, as far as I understand, broker
>put the messages to be consumed by that "dead" consumer so eventually they
>would not be processed and end up in DLQ. Of course, after timeout, consumer
>will become disconnected as ActiveMQ will be aware of broken transport, but
>remaining messages would not be delivered to other consumers.
>
>What is the best approach to deal with such situation (messages put to
>"dead" consumer to be handled by another consumer). Message redelivery?
>Probably there is some simpler approach and I'm simply missing some XML
>configuration for such stuff. Though, as my broker is embedded, I can create
>any "hooks" to provide necessary functionality if necessary.
>
>--
>View this message in context: http://activemq.2283324.n4.nabble.com/Proper-handling-of-disconnected-consumers-best-approach-tp4161875p4161875.html
>Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Re:Proper handling of disconnected consumers - best approach

romanhawk
I've created pretty simple producers/Consumers with AUTO_ACK mode. Setting prefetch to 0 made the system work as I expected. Maximum 1 message was stuck for some time unless connection was declared "dead". At that moment the message was handled by another alive consumer. Thanks for support, apparently prefetch size should be decreased to make consumers "pull" for messages. Otherwise dead consumer will "eat" messages until it would be declared "dead" (depends on timeout).