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 cause?
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 threw.
- Martin
>________________________________
> From: Gary Tully <gary.tu...@gmail.com>
> To: Martin Lichtin <lich...@yahoo.com>; ActiveMQ Users
> <users@activemq.apache.org>
> 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 <lich...@yahoo.com.invalid> 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
