You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Demian Mrakovich (JIRA)" <ji...@apache.org> on 2008/07/10 18:32:00 UTC

[jira] Created: (AMQ-1853) Optional non-blocking redelivery

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


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.


Re: [jira] Commented: (AMQ-1853) Optional non-blocking redelivery

Posted by Demian Mrakovich <ne...@hotmail.com>.
Dmitry, 
Does that mean you have disabled redelivery in AMQ and actually implementing
your own redelivery mechanism by dispatching failed messages back on queue? 

I think having to do workarounds like that warrants added functionality in
AMQ to support this ;)


JIRA jira@apache.org wrote:
> 
> 
>     [
> https://issues.apache.org/activemq/browse/AMQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44178#action_44178
> ] 
> 
> Dmitry Tsigelnik commented on AMQ-1853:
> ---------------------------------------
> 
> We have the same problem. We solve it in the next way: I wrap
> MessageListener by another, and if main MessageListener throws Exception
> wrapper redirect this mesage to sibling queue. This sibling queue listen
> the same MessageListener and good messages is not blocked
> 
>> 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
>>
>> 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.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-jira--Created%3A-%28AMQ-1853%29-Optional-non-blocking-redelivery-tp18386891p18401965.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[jira] Commented: (AMQ-1853) Optional non-blocking redelivery

Posted by "John Miller (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Commented: (AMQ-1853) Optional non-blocking redelivery

Posted by "Dmitry Tsigelnik (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/AMQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44178#action_44178 ] 

Dmitry Tsigelnik commented on AMQ-1853:
---------------------------------------

We have the same problem. We solve it in the next way: I wrap MessageListener by another, and if main MessageListener throws Exception wrapper redirect this mesage to sibling queue. This sibling queue listen the same MessageListener and good messages is not blocked

> 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
>
> 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.


[jira] Commented: (AMQ-1853) Optional non-blocking redelivery

Posted by "John Miller (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/AMQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48165#action_48165 ] 

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

This bug is present int ActiveMQ 5.1 and 5.2

> 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.


[jira] Commented: (AMQ-1853) Optional non-blocking redelivery

Posted by "Paul Hodchenkov (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/AMQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61705#action_61705 ] 

Paul Hodchenkov commented on AMQ-1853:
--------------------------------------

This is still reproducable in 5.4 .

> 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: NEEDS_REVIEWED
>
>
> 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.