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 > > >
