[
https://issues.apache.org/jira/browse/AMQ-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061282#comment-13061282
]
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: https://issues.apache.org/jira/browse/AMQ-3394
> 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 semantics.
> 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: http://www.atlassian.com/software/jira
