Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 7 Jul 2011 07:41:16 +0000 (UTC)
From: "Gary Tully (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <1974112233.6443.1310024476756.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <444238503.998.1309882097034.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (AMQ-3394) Better Fault Tolerance
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMQ-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061098#comment-13061098 ] 

Gary Tully commented on AMQ-3394:
---------------------------------

can you provide a test case that captures this use case? currently a redispatch of an in-flight message is tied to consumer close. I guess you want that tied to a timer? the abort slow consumer policy is one way to tie the death of a consumer to a timer. is that close to what you want?

> 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