What happens with JMSRedelivered when server moves message to DLQ

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

What happens with JMSRedelivered when server moves message to DLQ

Martin Lichtin
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
Reply | Threaded
Open this post in threaded view
|

Re: What happens with JMSRedelivered when server moves message to DLQ

gtully
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: What happens with JMSRedelivered when server moves message to DLQ

Martin Lichtin
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 <[hidden email]>
> To: Martin Lichtin <[hidden email]>; ActiveMQ Users <[hidden email]>
> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: What happens with JMSRedelivered when server moves message to DLQ

Martin Lichtin
Trying to understand why dlqDeliveryFailureCause has a 'null' value, it seems that in ActiveMQMessageConsumer.dispatch() the code

                            } catch (RuntimeException e) {
                                LOG.error(getConsumerId() + " Exception while processing message: " + md.getMessage().getMessageId(), e);
                                if (isAutoAcknowledgeBatch() || isAutoAcknowledgeEach() || session.isIndividualAcknowledge()) {
                                    // schedual redelivery and possible dlq processing
                                    md.setRollbackCause(e);
                                    rollback();
                                } else {
                                    // Transacted or Client ack: Deliver the
                                    // next message.
                                    afterMessageIsConsumed(md, false);
                                }
                            }
should also set md.setRollbackCause(e) in the else clause?
- Martin

 
      From: Martin Lichtin <[hidden email]>
 To: Gary Tully <[hidden email]>; ActiveMQ Users <[hidden email]>
 Sent: Wednesday, November 4, 2015 12:32 PM
 Subject: Re: What happens with JMSRedelivered when server moves message to DLQ
   
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 <[hidden email]>
> To: Martin Lichtin <[hidden email]>; ActiveMQ Users <[hidden email]>
> 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 <[hidden email]> 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


   
Reply | Threaded
Open this post in threaded view
|

Re: What happens with JMSRedelivered when server moves message to DLQ

gtully
I don't know, seems that branch does not result in rollback, but maybe it
does eventually and then the cause is missing.

A variant of the MessageListenerRedeliveryTest should prove it.

https://github.com/apache/activemq/blob/d6682e5476cd8cbefca04227ffa26a5d508d2494/activemq-unit-tests/src/test/java/org/apache/activemq/MessageListenerRedeliveryTest.java#L333

On Thu, 12 Nov 2015 at 11:23 Martin Lichtin <[hidden email]> wrote:

> Trying to understand why dlqDeliveryFailureCause has a 'null' value, it
> seems that in ActiveMQMessageConsumer.dispatch() the code
>
>                             } catch (RuntimeException e) {
>                                 LOG.error(getConsumerId() + " Exception
> while processing message: " + md.getMessage().getMessageId(), e);
>                                 if (isAutoAcknowledgeBatch() ||
> isAutoAcknowledgeEach() || session.isIndividualAcknowledge()) {
>                                     // schedual redelivery and possible
> dlq processing
>                                     md.setRollbackCause(e);
>                                     rollback();
>                                 } else {
>                                     // Transacted or Client ack: Deliver
> the
>                                     // next message.
>                                     afterMessageIsConsumed(md, false);
>                                 }
>                             }
>
> should also set md.setRollbackCause(e) in the else clause?
>
> - Martin
>
> ------------------------------
> *From:* Martin Lichtin <[hidden email]>
> *To:* Gary Tully <[hidden email]>; ActiveMQ Users <
> [hidden email]>
> *Sent:* Wednesday, November 4, 2015 12:32 PM
>
>
> *Subject:* Re: What happens with JMSRedelivered when server moves message
> to DLQ
>
>
> 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 <[hidden email]>
> > To: Martin Lichtin <[hidden email]>; ActiveMQ Users <
> [hidden email]>
> > 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 <[hidden email]>
> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: What happens with JMSRedelivered when server moves message to DLQ

Martin Lichtin
I believe that branch is for transacted sessions (which I'm also using).
If the test would use a transacted session, I'd say it no longer sees the cause.

On 12.11.2015 13:58, Gary Tully wrote:

> I don't know, seems that branch does not result in rollback, but maybe it
> does eventually and then the cause is missing.
>
> A variant of the MessageListenerRedeliveryTest should prove it.
>
> https://github.com/apache/activemq/blob/d6682e5476cd8cbefca04227ffa26a5d508d2494/activemq-unit-tests/src/test/java/org/apache/activemq/MessageListenerRedeliveryTest.java#L333
>
> On Thu, 12 Nov 2015 at 11:23 Martin Lichtin <[hidden email]> wrote:
>
>> Trying to understand why dlqDeliveryFailureCause has a 'null' value, it
>> seems that in ActiveMQMessageConsumer.dispatch() the code
>>
>>                              } catch (RuntimeException e) {
>>                                  LOG.error(getConsumerId() + " Exception
>> while processing message: " + md.getMessage().getMessageId(), e);
>>                                  if (isAutoAcknowledgeBatch() ||
>> isAutoAcknowledgeEach() || session.isIndividualAcknowledge()) {
>>                                      // schedual redelivery and possible
>> dlq processing
>>                                      md.setRollbackCause(e);
>>                                      rollback();
>>                                  } else {
>>                                      // Transacted or Client ack: Deliver
>> the
>>                                      // next message.
>>                                      afterMessageIsConsumed(md, false);
>>                                  }
>>                              }
>>
>> should also set md.setRollbackCause(e) in the else clause?
>>
>> - Martin
>>
>> ------------------------------
>> *From:* Martin Lichtin <[hidden email]>
>> *To:* Gary Tully <[hidden email]>; ActiveMQ Users <
>> [hidden email]>
>> *Sent:* Wednesday, November 4, 2015 12:32 PM
>>
>>
>> *Subject:* Re: What happens with JMSRedelivered when server moves message
>> to DLQ
>>
>>
>> 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 <[hidden email]>
>>> To: Martin Lichtin <[hidden email]>; ActiveMQ Users <
>> [hidden email]>
>>> 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 <[hidden email]>
>> 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
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Re: What happens with JMSRedelivered when server moves message to DLQ

Tim Bain
Martin,

Gary's suggestion that you create a unit test to confirm the incorrect
behavior is a good one.  Also submit a bug in JIRA for this.

Tim
On Nov 12, 2015 11:51 AM, "Martin Lichtin" <[hidden email]>
wrote:

> I believe that branch is for transacted sessions (which I'm also using).
> If the test would use a transacted session, I'd say it no longer sees the
> cause.
>
> On 12.11.2015 13:58, Gary Tully wrote:
>
>> I don't know, seems that branch does not result in rollback, but maybe it
>> does eventually and then the cause is missing.
>>
>> A variant of the MessageListenerRedeliveryTest should prove it.
>>
>>
>> https://github.com/apache/activemq/blob/d6682e5476cd8cbefca04227ffa26a5d508d2494/activemq-unit-tests/src/test/java/org/apache/activemq/MessageListenerRedeliveryTest.java#L333
>>
>> On Thu, 12 Nov 2015 at 11:23 Martin Lichtin <[hidden email]> wrote:
>>
>> Trying to understand why dlqDeliveryFailureCause has a 'null' value, it
>>> seems that in ActiveMQMessageConsumer.dispatch() the code
>>>
>>>                              } catch (RuntimeException e) {
>>>                                  LOG.error(getConsumerId() + " Exception
>>> while processing message: " + md.getMessage().getMessageId(), e);
>>>                                  if (isAutoAcknowledgeBatch() ||
>>> isAutoAcknowledgeEach() || session.isIndividualAcknowledge()) {
>>>                                      // schedual redelivery and possible
>>> dlq processing
>>>                                      md.setRollbackCause(e);
>>>                                      rollback();
>>>                                  } else {
>>>                                      // Transacted or Client ack: Deliver
>>> the
>>>                                      // next message.
>>>                                      afterMessageIsConsumed(md, false);
>>>                                  }
>>>                              }
>>>
>>> should also set md.setRollbackCause(e) in the else clause?
>>>
>>> - Martin
>>>
>>> ------------------------------
>>> *From:* Martin Lichtin <[hidden email]>
>>> *To:* Gary Tully <[hidden email]>; ActiveMQ Users <
>>> [hidden email]>
>>> *Sent:* Wednesday, November 4, 2015 12:32 PM
>>>
>>>
>>> *Subject:* Re: What happens with JMSRedelivered when server moves message
>>> to DLQ
>>>
>>>
>>> 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 <[hidden email]>
>>>> To: Martin Lichtin <[hidden email]>; ActiveMQ Users <
>>>>
>>> [hidden email]>
>>>
>>>> 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 <[hidden email]>
>>>>
>>> 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
>>>>
>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: What happens with JMSRedelivered when server moves message to DLQ

Martin Lichtin
Right, it's https://issues.apache.org/jira/browse/AMQ-6042

> On 14 Nov 2015, at 18:29, Tim Bain <[hidden email]> wrote:
>
> Martin,
>
> Gary's suggestion that you create a unit test to confirm the incorrect
> behavior is a good one.  Also submit a bug in JIRA for this.
>
> Tim
> On Nov 12, 2015 11:51 AM, "Martin Lichtin" <[hidden email]>
> wrote:
>
>> I believe that branch is for transacted sessions (which I'm also using).
>> If the test would use a transacted session, I'd say it no longer sees the
>> cause.
>>
>>> On 12.11.2015 13:58, Gary Tully wrote:
>>>
>>> I don't know, seems that branch does not result in rollback, but maybe it
>>> does eventually and then the cause is missing.
>>>
>>> A variant of the MessageListenerRedeliveryTest should prove it.
>>>
>>>
>>> https://github.com/apache/activemq/blob/d6682e5476cd8cbefca04227ffa26a5d508d2494/activemq-unit-tests/src/test/java/org/apache/activemq/MessageListenerRedeliveryTest.java#L333
>>>
>>> On Thu, 12 Nov 2015 at 11:23 Martin Lichtin <[hidden email]> wrote:
>>>
>>> Trying to understand why dlqDeliveryFailureCause has a 'null' value, it
>>>> seems that in ActiveMQMessageConsumer.dispatch() the code
>>>>
>>>>                             } catch (RuntimeException e) {
>>>>                                 LOG.error(getConsumerId() + " Exception
>>>> while processing message: " + md.getMessage().getMessageId(), e);
>>>>                                 if (isAutoAcknowledgeBatch() ||
>>>> isAutoAcknowledgeEach() || session.isIndividualAcknowledge()) {
>>>>                                     // schedual redelivery and possible
>>>> dlq processing
>>>>                                     md.setRollbackCause(e);
>>>>                                     rollback();
>>>>                                 } else {
>>>>                                     // Transacted or Client ack: Deliver
>>>> the
>>>>                                     // next message.
>>>>                                     afterMessageIsConsumed(md, false);
>>>>                                 }
>>>>                             }
>>>>
>>>> should also set md.setRollbackCause(e) in the else clause?
>>>>
>>>> - Martin
>>>>
>>>> ------------------------------
>>>> *From:* Martin Lichtin <[hidden email]>
>>>> *To:* Gary Tully <[hidden email]>; ActiveMQ Users <
>>>> [hidden email]>
>>>> *Sent:* Wednesday, November 4, 2015 12:32 PM
>>>>
>>>>
>>>> *Subject:* Re: What happens with JMSRedelivered when server moves message
>>>> to DLQ
>>>>
>>>>
>>>> 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 <[hidden email]>
>>>>> To: Martin Lichtin <[hidden email]>; ActiveMQ Users <
>>>>>
>>>> [hidden email]>
>>>>
>>>>> 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 <[hidden email]>
>>>>>
>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>