activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Govoni (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3394) Better Fault Tolerance
Date Thu, 07 Jul 2011 13:06:17 GMT

    [ 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

        

Mime
View raw message