Right, it's https://issues.apache.org/jira/browse/AMQ-6042
> On 14 Nov 2015, at 18:29, Tim Bain <tb...@alumni.duke.edu> 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" <lich...@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 <lich...@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 <lich...@yahoo.com> >>>> *To:* Gary Tully <gary.tu...@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.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 >>>>> >>>> >>>> >>>> >>
