[
https://issues.apache.org/jira/browse/AMQ-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061274#comment-13061274
]
Darren Govoni commented on AMQ-3394:
------------------------------------
Hi Gary, thanks for the inquiry. I'm not sure co-mingling slow consumer policy
with this semantics will achieve the same, but I need to study it some more.
The test case or rather, workflow, would go something like this:
1. A "work" message is queued.
2. The "work" message is de-queued by consumer A. It is now off the queue (or
hidden) and the "work" is being performed by consumer A. However, the broker
has triggered the message's TTL (or some other time indicator) specified by the
producer who published it. Say 2 minutes for this message.
3. Consumer A is set to INDIVIDUAL_ACKNOWLEDGE and has not yet acknowledged the
message because it is attemping to process the "work" from it. If successful,
it will ACK the message.
4. Consumer A suffers a power outage while processing the message and never
ACKS it.
5. 2 minutes expire and the original "work" message re-appears on the queue
(presumably by the broker).
6. Consumer B receives the or9iginal "work" message, processes the work
successfully and ACKS the message after that (within 2 minutes). The message is
gone forever now. All are happy.
Does this make sense?
The idea for this comes from Amazon's Simple Queue Service which provides this
semantics.
> 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
