activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Bakker (JIRA)" <>
Subject [jira] [Commented] (AMQ-1853) Optional non-blocking redelivery
Date Thu, 28 Jul 2011 07:21:10 GMT


Mark Bakker commented on AMQ-1853:

Camel redelivery doesn't survive a server crash while redelivering. besides that the Camel
docs state to use the underlying message broker in production situations, because of loosing
messages when the Camel JVM gets stoped, killed, or crashes.

Besides this issue Camel redelivery will hold a thread while redelivering (not returning the
working thread to the consumer thread pool) and reducing the true put of consuming messages
of this queue in general. When the message in redelivery are equal to number of consumer threads
no new messages will get processed, and this time keep your finger crossed the server doesn't
need to turn of or crashes. A semi work around is to set the redelivery to a short time to
keep the system running, this will not fly for all usecases, and as stated it should not be
used as a production configuration.

> Optional non-blocking redelivery
> --------------------------------
>                 Key: AMQ-1853
>                 URL:
>             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:


View raw message