Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <17277534.6691289936004781.JavaMail.jira@thor>
Date: Tue, 16 Nov 2010 14:33:24 -0500 (EST)
From: "Kurt Roekle (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Commented: (AMQ-3003) Allow the option of a DLQ per durable
 subscription DeadLetterStrategy
In-Reply-To: <27936925.451288180920064.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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

Kurt Roekle commented on AMQ-3003:
----------------------------------

We've tried specifying the destination DLQ, but it did not respect that and still ended up in the topic DLQ.

> Allow the option of a DLQ per durable subscription DeadLetterStrategy
> ---------------------------------------------------------------------
>
>                 Key: AMQ-3003
>                 URL: https://issues.apache.org/activemq/browse/AMQ-3003
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 5.4.1
>            Reporter: Gary Tully
>             Fix For: 5.5.0
>
>
> From https://issues.apache.org/activemq/browse/AMQ-2584 - with durable subscriptions sharing the DLQ there will be duplicate sends to the dlq if more than one durable sub rejects the message. 
> These durables are suppressed provided they are not already acked, in which case the duplicate can hang about. The audit=false option for the DLQ works around this, but it begs the question, can I know which durable subscription refused a message.
> To facilitate this, having a DLQ pre durable sub is a nice option. It can use the clientId and subscriberName as the postfix, so ACTIVEMQ_DLQ.ClientId-SubscriberName - If the subscriber changes subsequent messages can go do a different DLQ. These destinations would need to be manually deleted when no longer needed.
> This will require additional methods in org.apache.activemq.broker.region.policy.DeadLetterStrategy so will need to a version update.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.