Redelivery policy not honored

View: New views
3 Messages — Rating Filter:   Alert me  

Redelivery policy not honored

by Adam Lewandowski :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

At what level does the redelivery policy get applied? I've got a
transactional consumer (Spring MDP) that is performing a rollback and I
am expecting the message to be redelivered a maximum number of times as
specified on the connection factory's redelivery policy. After the
maximum retry attempts, I'm expecting to see the message sent to the
dead letter queue as specified in the broker's destination policy map.
Instead, the message gets delivered over and over again, with an
increasing value for the JMSXDeliveryCount message property and never
gets placed on the dead letter queue. It looks as if the redelivery
policy isn't being honored.
The only place I could find in the code where the redelivery policy is
applied is at the MessageConsumer level (ActiveMQMessageConsumer). This
doesn't make sense to me since a different consumers could get the
message on repeated delivery attempts, correct? Spring's message
listener framework seems to confirm this as it uses a polling model,
creating a new MessageConsumer and Session once per second
(AbstractPollingMessageListenerContainer). Does AMQ expect that the same
MessageConsumer will be used for message redelivery in a transactional
setting?

Configuration:
Connection Factory:
    <bean id="jmsConnectionFactory"
        class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="vm://broker" />
        <property name="redeliveryPolicy">
            <bean class="org.apache.activemq.RedeliveryPolicy">
                <property name="maximumRedeliveries" value="2" />
            </bean>
        </property>
    </bean>

Broker:
    <broker brokerName="broker" persistent="true" useJmx="false"
        start="true" xmlns="http://activemq.org/config/1.0">
        <destinationPolicy>
            <policyMap>
                 <policyEntries>
                     <policyEntry queue="EventQueue">
                        <deadLetterStrategy>
                            <individualDeadLetterStrategy
queuePrefix="DEAD" />
                        </deadLetterStrategy>
                     </policyEntry>
                 </policyEntries>              
            </policyMap>
        </destinationPolicy>
        <transportConnectors>
            <transportConnector uri="vm://broker" />
        </transportConnectors>
    </broker>


Re: Redelivery policy not honored

by naga007 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Use CACHE_CONSUMER in Spring Message listener container, this will not create session and consumer everytime its polls.




Adam Lewandowski wrote:
At what level does the redelivery policy get applied? I've got a
transactional consumer (Spring MDP) that is performing a rollback and I
am expecting the message to be redelivered a maximum number of times as
specified on the connection factory's redelivery policy. After the
maximum retry attempts, I'm expecting to see the message sent to the
dead letter queue as specified in the broker's destination policy map.
Instead, the message gets delivered over and over again, with an
increasing value for the JMSXDeliveryCount message property and never
gets placed on the dead letter queue. It looks as if the redelivery
policy isn't being honored.
The only place I could find in the code where the redelivery policy is
applied is at the MessageConsumer level (ActiveMQMessageConsumer). This
doesn't make sense to me since a different consumers could get the
message on repeated delivery attempts, correct? Spring's message
listener framework seems to confirm this as it uses a polling model,
creating a new MessageConsumer and Session once per second
(AbstractPollingMessageListenerContainer). Does AMQ expect that the same
MessageConsumer will be used for message redelivery in a transactional
setting?

Configuration:
Connection Factory:
    <bean id="jmsConnectionFactory"
        class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="vm://broker" />
        <property name="redeliveryPolicy">
            <bean class="org.apache.activemq.RedeliveryPolicy">
                <property name="maximumRedeliveries" value="2" />
            </bean>
        </property>
    </bean>

Broker:
    <broker brokerName="broker" persistent="true" useJmx="false"
        start="true" xmlns="http://activemq.org/config/1.0">
        <destinationPolicy>
            <policyMap>
                 <policyEntries>
                     <policyEntry queue="EventQueue">
                        <deadLetterStrategy>
                            <individualDeadLetterStrategy
queuePrefix="DEAD" />
                        </deadLetterStrategy>
                     </policyEntry>
                 </policyEntries>              
            </policyMap>
        </destinationPolicy>
        <transportConnectors>
            <transportConnector uri="vm://broker" />
        </transportConnectors>
    </broker>

Re: Redelivery policy not honored

by Adam Lewandowski :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks, that worked. But only if setting sessionTransacted to true and
not using an external transaction manager, which rules out XA transactions.

I'm still unconvinced that implementing the redelivery policy in the
MessageConsumer is appropriate or even correct. If you have two
consumers on the same queue they could very easily just bounce the
message back and forth and the maxDeliveryAttempts will never be
reached. Doesn't seem right does it, or am I missing something?


naga007 wrote:

> Use CACHE_CONSUMER in Spring Message listener container, this will not create
> session and consumer everytime its polls.
>
>
>
>
>
> Adam Lewandowski wrote:
>  
>> At what level does the redelivery policy get applied? I've got a
>> transactional consumer (Spring MDP) that is performing a rollback and I
>> am expecting the message to be redelivered a maximum number of times as
>> specified on the connection factory's redelivery policy. After the
>> maximum retry attempts, I'm expecting to see the message sent to the
>> dead letter queue as specified in the broker's destination policy map.
>> Instead, the message gets delivered over and over again, with an
>> increasing value for the JMSXDeliveryCount message property and never
>> gets placed on the dead letter queue. It looks as if the redelivery
>> policy isn't being honored.
>> The only place I could find in the code where the redelivery policy is
>> applied is at the MessageConsumer level (ActiveMQMessageConsumer). This
>> doesn't make sense to me since a different consumers could get the
>> message on repeated delivery attempts, correct? Spring's message
>> listener framework seems to confirm this as it uses a polling model,
>> creating a new MessageConsumer and Session once per second
>> (AbstractPollingMessageListenerContainer). Does AMQ expect that the same
>> MessageConsumer will be used for message redelivery in a transactional
>> setting?
>>
>> Configuration:
>> Connection Factory:
>>     <bean id="jmsConnectionFactory"
>>         class="org.apache.activemq.ActiveMQConnectionFactory">
>>         <property name="brokerURL" value="vm://broker" />
>>         <property name="redeliveryPolicy">
>>             <bean class="org.apache.activemq.RedeliveryPolicy">
>>                 <property name="maximumRedeliveries" value="2" />
>>             </bean>
>>         </property>
>>     </bean>
>>
>> Broker:
>>     <broker brokerName="broker" persistent="true" useJmx="false"
>>         start="true" xmlns="http://activemq.org/config/1.0">
>>         <destinationPolicy>
>>             <policyMap>
>>                  <policyEntries>
>>                      <policyEntry queue="EventQueue">
>>                         <deadLetterStrategy>
>>                             <individualDeadLetterStrategy
>> queuePrefix="DEAD" />
>>                         </deadLetterStrategy>
>>                      </policyEntry>
>>                  </policyEntries>              
>>             </policyMap>
>>         </destinationPolicy>
>>         <transportConnectors>
>>             <transportConnector uri="vm://broker" />
>>         </transportConnectors>
>>     </broker>
>>
>>
>>
>>    
>
>