Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 6 Mar 2013 11:20:17 +0000 (UTC)
From: "Martin Lichtin (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12595589.1340375334763.391014.1362568817325@arcas>
In-Reply-To: <JIRA.12595589.1340375334763@arcas>
References: <JIRA.12595589.1340375334763@arcas>
Subject: [jira] [Commented] (AMQ-3894) Add support for Broker based
 redelivery
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Martin Lichtin commented on AMQ-3894:
-------------------------------------

A useful feature!
XML tidbit, it's <redeliveryPolicyEntries>

Also, when setting sendToDlqIfMaxRetriesExceeded="false", a message gets silently dropped
when max retries is reached. Expected, and if so, worth documenting?
I'd have expected the message stays in the queue.
                
> Add support for Broker based redelivery
> ---------------------------------------
>
>                 Key: AMQ-3894
>                 URL: https://issues.apache.org/jira/browse/AMQ-3894
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.7.0
>
>
> redelivery is handled by the consumer, so client side. messages pending redelivery are seen as inflight by the broker and not available to other consumers. It is possible to break the order constraint and receive messages backed up behind a message pending redelivery, but this is all local to the client consumer.
> When redelivery is exhausted, the message is returned to the broker with a poison ack, which the broker responds by removing the message and doing Dead letter queue processing (DLQ).
> This enhancement will allow a replacement of DLQ handling that will handle redelivery. It is based on the ideas outlined and implemented by a camel route in https://issues.apache.org/jira/browse/AMQ-2710 
> The idea is a BrokerPlugin will override sendToDeadLetterQueue and resend the message to the original destination in accordance with a matching RedeliveryPolicy. The resend will use the broker schedular to implement the delayed send after the message has been acked as poison by the consumer.
> So the message will essentially be enqueued at the tail of the queue and dispatched again to any available consumer.
> If retries are exceeded or there is no matching redelivery policy for a destination, normal DLQ processing will take place.
> This will work in conjunction with consumer/client redelivery exhaustion or using a redelivery policy in the url query of jms.redeliveryPolicy.maximumRedeliveries=0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira