activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] [Commented] (AMQ-3394) Better Fault Tolerance
Date Thu, 07 Jul 2011 13:20:16 GMT


Gary Tully commented on AMQ-3394:

I think this is already the behavior once there is some inactivity timeout on the connection.
At (4), the jms connection dies, the consumer dies and any unacked messages are scheduled
for redelivery.

Where the AbortSlowConsumerPolicy comes in to play is where at (4), the consumer stops responding
but the JMS connection is still available. In this case, the connection will not die and the
consumer will not go away. The broker sees this as a slowConsumer, the abort policy allows
the broker to force a consumer/connection closure such that unacked messages are released
after some timeout.

Keep, studying, there may well be a need for such an enhancement, I just don't see it in that
use case, but I may be missing something.

> Better Fault Tolerance
> ----------------------
>                 Key: AMQ-3394
>                 URL:
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 5.5.0
>            Reporter: Darren Govoni
> Other queue technologies provide a manner of fault tolerance missing from AMQ message
> That is, messages can be acknowledged at any time by a client. Failing to do so within
the messages TTL, should result in the message re-appearing on the queue so another client
can re-try it.
> Reliable messaging with AMQ currently pertains to only message receipt, but in practical
systems distributing work via a queue this is unsufficient semantics to ensure tolerance of
faults "during" work processing. In that case, clients will only acknowledge a message in
the event of successful processing of that message (left to the client to decide). If the
client were to suffer a fatality during processing, the work associated with the message is
left undone in the current AMQ because it cannot be re-processed. In these extreme (but not
uncommon) fault conditions, it is not possible for the client to "re-queue" the message. 
> Combining TTL, re-queue behavior (in the Broker) and INDIVIDUAL_ACKNOWLEDGE (on the client)
of messages should achieve the desired increase in fault-tolerance described here.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message