activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Miller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1853) Optional non-blocking redelivery
Date Sun, 14 Dec 2008 10:07:05 GMT

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

John Miller commented on AMQ-1853:
----------------------------------

I have the same problem. When a message listener throws a RuntimeException, ActiveMQ tries
to re-deliver the same message according to redelivery policy, and the rest of the messages
are blocked until  the message which caused the exception  is redelivered with success or
put into the dead letters queue. I want my messages to be redelivered with initial redelivery
delay 10 seconds with back-off multiplier 3, maximum 2redelivery  attempts, exponential back-off
is on. It means that the messages in the queue are blocked for  10+30+90 = 130 seconds !

> Optional non-blocking redelivery
> --------------------------------
>
>                 Key: AMQ-1853
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1853
>             Project: ActiveMQ
>          Issue Type: Wish
>          Components: Broker
>    Affects Versions: 5.1.0
>            Reporter: Demian Mrakovich
>             Fix For: 5.3.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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message