[
https://issues.apache.org/activemq/browse/AMQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44099#action_44099
]
tsigelnik edited comment on AMQ-1847 at 7/9/08 1:27 AM:
---------------------------------------------------------------
Redelivery policy doesn't work with Spring's
org.springframework.jms.listener.DefaultMessageListenerContainer at all
That happens, because DefaultMessageListenerContainer closes the consumer,
session and connection, and do the reconnect if message listener throws
exception, and of course previous delivery timepoint is empty in the new
consumer.
It happens, because DefaultMessageListenerContainer doesn't know what a cause
of JMSException. Maybe it was disconnection... and ConnectionFactory haven't
reconnection logic...
I wrote my own simple MessageListenerContainer, that doesn't do reconnection if
JMSException is thrown, because ActiveMQConnectionFactory has reconnection logic
was (Author: tsigelnik):
Redelivery policy with spring isn't work with Spring's
org.springframework.jms.listener.DefaultMessageListenerContainer at all
That happens, because DefaultMessageListenerContainer closes the consumer,
session and connection, and do the reconnect if message listener throws
exception, and of course previous delivery timepoint is empty in the new
consumer.
It happens, because DefaultMessageListenerContainer doesn't know what a cause
of JMSException. Maybe it was disconnection... and ConnectionFactory haven't
reconnection logic...
I wrote my own simple MessageListenerContainer, that doesn't do reconnection if
JMSException is thrown, because ActiveMQConnectionFactory has reconnection logic
> Redelivery on a failure doesn't respect the initialRedeliveryDelay on the
> first attempt.
> ----------------------------------------------------------------------------------------
>
> Key: AMQ-1847
> URL: https://issues.apache.org/activemq/browse/AMQ-1847
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.1.0
> Environment: Linux, ActiveMQ 5.1, Spring 2.5.x with transacted
> DefaultMessageListenerContainer
> Reporter: Veit Guna
>
> Hi.
> I'm using ActiveMQ 5.1 together with Spring's DefaultMessageListenerContainer
> to enable MDPs. I'm using the redeliveryPolicy to enable redelivery on
> failures during consumption of a message. ActiveMQ configuration looks like
> this:
> <camelContext id="camel"
> xmlns="http://activemq.apache.org/camel/schema/spring";>
> <route errorHandlerRef="deadLetterErrorHandler">
> <from uri="activemq:NEW" />
> </route>
> </camelContext>
> <bean id="deadLetterErrorHandler"
> class="org.apache.camel.builder.DeadLetterChannelBuilder">
> <property name="redeliveryPolicy" ref="redeliveryPolicyConfig"/>
> </bean>
> <bean id="redeliveryPolicyConfig"
> class="org.apache.camel.processor.RedeliveryPolicy">
> <property name="maximumRedeliveries" value="4"/>
> <property name="initialRedeliveryDelay" value="30000"/>
> <property name="useExponentialBackOff" value="true"/>
> <property name="backOffMultiplier" value="2" />
> </bean>
> Now if a failure occurs, the configured delay isn't used on the first
> redelivery attempt. Instead redelivery takes place immediately after the
> failure occured. This sounds odd to me, since the property is even called
> initialRedeliveryDelay :). I know that maybe this was caused due to the
> following issue:
> https://issues.apache.org/activemq/browse/AMQ-1032
> In my opinion immediately redelivery isn't very useful in most cases. If a
> failure occurs, it won't be fixed some ms later :). So my suggestion is (in
> respect to AMQ-1032) to have two options:
> initialRedeliveryDelay
> redeliveryDelay
> So both configurations would be possible. For AMQ-1032 just configure
> initialRedeliveryDelay to 0. Otherwise just take the redeliveryDelay as
> initialRedeliveryDelay to get what I want :).
> Does this make sense?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
