activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Lichtin <>
Subject Re: What happens with JMSRedelivered when server moves message to DLQ
Date Wed, 04 Nov 2015 11:32:04 GMT
I'm not actually talking about the counter, but the Boolean flag 'JMSRedelivered'.
Anyways, you're right that it should work when setting persistJMSRedelivered=true (I forgot
about this option).

Regarding the "poison cause", is it not possible for the client side to return a non-null
For example, when a message ends up in DLQ, it has additional property:

dlqDeliveryFailureCause=java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
{destination = null, collisionAvoidanceFactor = 0.15, maximumRedeliveries = 0, maximumRedeliveryDelay
= -1, initialRedeliveryDelay = 1000, useCollisionAvoidance = false, useExponentialBackOff
= false, backOffMultiplier = 5.0, redeliveryDelay = 1000}, cause:null, 

This is nice, but pretty useless information.
A real value would be if "cause:null" would instead be shwoing the Exception that the application

- Martin

> From: Gary Tully <>
> To: Martin Lichtin <>; ActiveMQ Users <>

> Sent: Wednesday, November 4, 2015 11:52 AM
> Subject: Re: What happens with JMSRedelivered when server moves message to DLQ
> that is intended. the dlq enqueue is a new message. the poison cause property will have
some good information but it would make sense to add a property that captures the value of
that counter. the only issue is that the value is typically interpreted client side and remains
1 on the broker so it may be of limited value. if you want to depend on the redelivery counter
you may want to peek at the persistjmsredelivery option.
> On Tue 3 Nov 2015 3:45 PM Martin Lichtin <> wrote:
> I see the JMSRedelivered flag goes back to 'false' when # of redeliveries is exceeded
> and ActiveMQ server moving the message into the DLQ.
> Is this done on purpose? I'd rather expect the flag stay 'true', as this state should
be preserved.
> - Martin

View raw message