[
https://issues.apache.org/jira/browse/AMQ-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256638#comment-13256638
]
John Baker edited comment on AMQ-3285 at 4/18/12 3:24 PM:
----------------------------------------------------------
Hello,
I've got some information to add. I've debugged this and find the following
code being (correctly?) executed in ActiveMQMessageConsumer when a message is
rolled back:
{code}
if (redeliveryDelay > 0 && !unconsumedMessages.isClosed()) {
// Start up the delivery again a little later.
scheduler.executeAfterDelay(new Runnable() {
public void run() {
try {
if (started.get()) {
start();
}
} catch (JMSException e) {
session.connection.onAsyncException(e);
}
}
}, redeliveryDelay);
{code}
The value of redeliveryDelay (in ms) is correct. However, the "problem" is the
Spring DefaultMessageListener, which asks ActiveMQ for another message and it
gives back the message waiting for redelivery. I can see that the thread has
the same ID in the debugger, so I think the problem is better described as:
"ActiveMQ does not remove the message due for redelivery from the queue, but
gives it out next time it's asked to do so. After X retries, it's moved to the
DLQ and hence the listener will not receive it again when it asks for the next
message".
This is a very serious problem.
J
was (Author: jmbaker):
Hello,
I've got some information to add. I've debugged this and find the following
code being (correctly?) executed in ActiveMQMessageConsumer when a message is
rolled back:
if (redeliveryDelay > 0 && !unconsumedMessages.isClosed()) {
// Start up the delivery again a little later.
scheduler.executeAfterDelay(new Runnable() {
public void run() {
try {
if (started.get()) {
start();
}
} catch (JMSException e) {
session.connection.onAsyncException(e);
}
}
}, redeliveryDelay);
The value of redeliveryDelay (in ms) is correct. However, the "problem" is the
Spring DefaultMessageListener, which asks ActiveMQ for another message and it
gives back the message waiting for redelivery. I can see that the thread has
the same ID in the debugger, so I think the problem is better described as:
"ActiveMQ does not remove the message due for redelivery from the queue, but
gives it out next time it's asked to do so. After X retries, it's moved to the
DLQ and hence the listener will not receive it again when it asks for the next
message".
This is a very serious problem.
J
> ActiveMQXAConnectionFactory does not respect various parameters for
> redelivery policy
> -------------------------------------------------------------------------------------
>
> Key: AMQ-3285
> URL: https://issues.apache.org/jira/browse/AMQ-3285
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.4.0, 5.4.2, 5.5.0
> Reporter: Jaskirat Bhatia
> Attachments: activemq-test-0.1-project.zip, activemq-test.zip
>
>
> I tried to add these following parameters to my redelivery policy and
> activeMQ is not respecting any of them except maximumRedelivery
> <spring:bean id="redeliveryPolicy"
> class="org.apache.activemq.RedeliveryPolicy">
> <spring:property name="maximumRedeliveries" value="5"/>
> <spring:property name="initialRedeliveryDelay"
> value="5000"/>
> <spring:property
> name="redeliveryDelay" value="2000"/>
> <spring:property name="useExponentialBackOff"
> value="true"/>
> <spring:property name="backOffMultiplier" value="2"/>
> </spring:bean>
> I have attached the project which I took from
> https://issues.apache.org/jira/browse/AMQ-1593 and added the above parameter
> to my brokerURL:
> tcp://localhost:5000?jms.redeliveryPolicy.maximumRedeliveries=3&jms.redeliveryPolicy.initialRedeliveryDelay=10000&jms.redeliveryPolicy.deliveryDelay=10000&jms.redeliveryPolicy.useExponentialBackOff=true&jms.redeliveryPolicy.backOffMultiplier=2
> This test case will show you that none of the parameters like
> initiaRedeliveryDelay etc will take effect, except maxRedeliveries
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
