You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Dmitry Tsigelnik (JIRA)" <ji...@apache.org> on 2008/07/10 21:30:00 UTC
[jira] Commented: (AMQ-1853) Optional non-blocking redelivery
[ 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.
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.