RedeliveryPolicy not working with Springs DefaultMessageListenerContainer

[Marek Neumann <ma...@jestadigital.com>]

Hi,

we set up an ActiveMQ Spring configuration:

<bean id="queueConnectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory">
       <property name="connectionFactory">
          <bean class="org.apache.activemq.ActiveMQConnectionFactory">
            <property name="brokerURL">
               <value>${amq.broker.url}</value>
            </property>
         <property name="redeliveryPolicy" ref="amqRedeliveryPolicy" />
       </bean>
      </property>
   </bean>

with a defined Redelivery Policy:

<bean id="amqRedeliveryPolicy" class="org.apache.activemq.RedeliveryPolicy">
      <property name="useExponentialBackOff" value="true" />
      <property name="backOffMultiplier" value="2" />
      <property name="initialRedeliveryDelay" value="1000" />
      <property name="maximumRedeliveries" value="5" />
</bean>

We are using Springs DefaultMessageListenerContainer.

Problem is that the redelivery works but without using the additional
configured params (message is redelivered with very short intervals
until the maximum is reached, then sent to DLQ). When debugging we found
out that the redelivery delay is calculated in ActiveMQMessageConsumer.
However, there are different consumers available, so it always gets
initialized with the default value:

if (currentRedeliveryCount > 0) {
     redeliveryDelay =
redeliveryPolicy.getNextRedeliveryDelay(redeliveryDelay);
} else {
     redeliveryDelay = redeliveryPolicy.getInitialRedeliveryDelay();
 }

Does somebody have an idea how to make this work? Is there any
configuration problem? We have also tried to set the "cacheLevelName" as
recommended in some threads - without success.

Thanks,

Marek

Reply:RedeliveryPolicy not working with Springs DefaultMessageListenerContainer

[SuoNayi <su...@163.com>]

Hi  Marek,it should work because the consumer of amq will try to catch runtime expection if messageListener fails to process message.
Then the message will be redispatch to the messageListener again if not out of the max delivery times.
I have found that spring's SimpleMessageListenerContainer will swallow all exceptions instead of propagating exception to the underlying so redelivery will not work on that.
 

At 2011-11-14 22:09:20,"Marek Neumann" <ma...@jestadigital.com> wrote:
>Hi,
>
>we set up an ActiveMQ Spring configuration:
>
><bean id="queueConnectionFactory"
>class="org.apache.activemq.pool.PooledConnectionFactory">
>       <property name="connectionFactory">
>          <bean class="org.apache.activemq.ActiveMQConnectionFactory">
>            <property name="brokerURL">
>               <value>${amq.broker.url}</value>
>            </property>
>         <property name="redeliveryPolicy" ref="amqRedeliveryPolicy" />
>       </bean>
>      </property>
>   </bean>
>
>with a defined Redelivery Policy:
>
><bean id="amqRedeliveryPolicy" class="org.apache.activemq.RedeliveryPolicy">
>      <property name="useExponentialBackOff" value="true" />
>      <property name="backOffMultiplier" value="2" />
>      <property name="initialRedeliveryDelay" value="1000" />
>      <property name="maximumRedeliveries" value="5" />
></bean>
>
>We are using Springs DefaultMessageListenerContainer.
>
>Problem is that the redelivery works but without using the additional
>configured params (message is redelivered with very short intervals
>until the maximum is reached, then sent to DLQ). When debugging we found
>out that the redelivery delay is calculated in ActiveMQMessageConsumer.
>However, there are different consumers available, so it always gets
>initialized with the default value:
>
>if (currentRedeliveryCount > 0) {
>     redeliveryDelay =
>redeliveryPolicy.getNextRedeliveryDelay(redeliveryDelay);
>} else {
>     redeliveryDelay = redeliveryPolicy.getInitialRedeliveryDelay();
> }
>
>Does somebody have an idea how to make this work? Is there any
>configuration problem? We have also tried to set the "cacheLevelName" as
>recommended in some threads - without success.
>
>Thanks,
>
>Marek