activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Re: What happens with JMSRedelivered when server moves message to DLQ
Date Sat, 14 Nov 2015 17:29:57 GMT
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" <lichtin@yahoo.com.invalid>
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 <lichtin@yahoo.com> 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 <lichtin@yahoo.com>
>>> *To:* Gary Tully <gary.tully@gmail.com>; ActiveMQ Users <
>>> users@activemq.apache.org>
>>> *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 <gary.tully@gmail.com>
>>>> To: Martin Lichtin <lichtin@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 <lichtin@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
>>>>
>>>
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message