activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Piotrowski (Commented) (JIRA)" <>
Subject [jira] [Commented] (AMQ-1853) Optional non-blocking redelivery
Date Wed, 01 Feb 2012 13:57:03 GMT


Michael Piotrowski commented on AMQ-1853:

I see a problem. I downloaded AMQ 5.6-SNAPSHOT, configured it and my ConnectionFactory (wrapped)
bean looks like this:

<bean id="jmsConnectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory"
		<property name="connectionFactory">
			<bean class="org.apache.activemq.ActiveMQConnectionFactory">
				<property name="brokerURL">
				<property name="redeliveryPolicy">
					<bean class="org.apache.activemq.RedeliveryPolicy">
						<property name="maximumRedeliveries" value="4"/>    
						<property name="initialRedeliveryDelay" value="3000"/>
						<property name="useExponentialBackOff" value="true"/>
					<property name="backOffMultiplier" value="2"/>						
				<property name="nonBlockingRedelivery" value="true" />				

The problem is that if 'nonBlockingRedelivery' is set to TRUE AFTER RedeliveryPolicy property,
redelivering takes much more time than specified in RedeliveryPolicy object properties. On
the other hand - while 'nonBlockingRedelivery' is put BEFORE declaration od RedeliveryPolicy
- it takes under consideration only 'maximumRedeliveries' property - but with no delay and
multiplier. That makes whole redelivery thing totally wrong - i got defult 6 requests one
by one. 

Is this normal and expected behaviour? How can I achieve taking redeliveryPolicy properties
to run?
> Optional non-blocking redelivery
> --------------------------------
>                 Key: AMQ-1853
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Wish
>          Components: Broker
>    Affects Versions: 5.1.0
>            Reporter: Demian Mrakovich
>            Assignee: Timothy Bish
>             Fix For: 5.6.0
>         Attachments:
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message