Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 24 Aug 2011 15:46:29 +0000 (UTC)
From: "Fengming Lou (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <784031223.9625.1314200789489.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (AMQ-1853) Optional non-blocking redelivery
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Fengming Lou commented on AMQ-1853:
-----------------------------------

Since a message goes to dead letter queue once maximumRedeliveries is exceeded. One "work around" is to take advantage of individualDeadLetterStrategy. By shortening the maximuRedelieveries with the following configuration, the message will go back to the original queue and not to block new messages.
	<deadLetterStrategy>
		<individualDeadLetterStrategy queuePrefix="BACK.TO.WHERE.IT.FROM" useQueueForQueueMessages="true" />
    </deadLetterStrategy>

> Optional non-blocking redelivery
> --------------------------------
>
>                 Key: AMQ-1853
>                 URL: https://issues.apache.org/jira/browse/AMQ-1853
>             Project: ActiveMQ
>          Issue Type: Wish
>          Components: Broker
>    Affects Versions: 5.1.0
>            Reporter: Demian Mrakovich
>             Fix For: 5.6.0
>
>
> When a message is redelivered the consumer blocks for the amount of time specified by the redelivery delay. For a high load scenario where message order is irrelevant this is just reducing performance and will result in a complete halt if the delay is long and several bad messages are consumed in a short time. 
> I think what I basically wish for is how it worked in versions 3.x, prior to fix for AMQ-268. So I would very much like to have configurable option to NOT block consumers when redelivering messages. 
> If no-one feels up to it, I'd still appreciate some hints and I could try to fix it myself. Looking at ActiveMQMessageConsumer.rollback(), I was thinking something in the lines of just scheduling a task to put the message back on queue after a delay - if configured to, instead of stopping delivery and a schedule a task to resume delivery again. But I do not possess an understanding of AMQ thorough enough to predict potential side effects of this, so any analysis would be helpful.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira