There is an originalExpiration message property that is set when a message is sent to the DLQ, if this is non zero it is an indication that the message expired, but it is not a guarantee. The other relevant property is the redeliveryCounter, a value > 6 would indicate that the default number of retries was exceeded.
agreed, it would be nice enhancement to get more detail reason codes in there if possible. All contributions welcome. some more relevant DLQ info at: http://activemq.apache.org/message-redelivery-and-dlq-handling.html On 21 January 2012 23:07, Jason Dillon <ja...@planet57.com> wrote: > BTW, is there an easy way to via JMX look at the DLQ messages and determine > if they were sent here due to expiration? I didn't see any hints when I > looked that the messages had been expired and thus sent to the DLQ. Perhaps > the messages should get a property attached to explain the reason for DLQ > delivery? Something like a "dlqDeliveryReason" which could be "expired" or > "failure" and on "failure" you can go look at "dlqDeliveryFailureCause" for > more detail. > > Are there any other reasons why a message might be sent to the DLQ? > > --jason > > > On Jan 21, 2012, at 2:29 PM, Jason Dillon wrote: > >> Doh! I didn't realize (or maybe I just forgot) that expired messages are >> sent to the DLQ by default. >> >> I also didn't realize that the JMSDestination on messages sent to a virtual >> topic will retain the virtual topic destination and not the consumer queue >> destination. >> >> --jason >> >> On Jan 20, 2012, at 2:20 AM, Gary Tully wrote: >> >>> org.apache.activemq.broker.region.virtual.VirtualTopicInterceptor#send >>> >>> which calls: org.apache.activemq.broker.region.DestinationFilter#send >>> >>> On 20 January 2012 01:48, Jason Dillon <ja...@planet57.com> wrote: >>>> Can you point me at the code which handles virtual topic subscription >>>> message propagation to consumer queues plz? >>>> >>>> --jason >>>> >>>> >>>> On Jan 19, 2012, at 12:36 PM, Gary Tully wrote: >>>> >>>>> should be, but the use case is narrow, see the test case: >>>>> http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/MessageListenerRedeliveryTest.java?r1=1084175&r2=1084174&pathrev=1084175 >>>>> >>>>> On 19 January 2012 19:09, Jason Dillon <ja...@planet57.com> wrote: >>>>>> Is this change in 5.5.1 and enabled by default? >>>>>> >>>>>> If so I don't see any of these properties set. >>>>>> >>>>>> --jason >>>>>> >>>>>> >>>>>> On Jan 19, 2012, at 7:32 AM, Gary Tully wrote: >>>>>> >>>>>>> For one use case, when a exception causes a rollback, that exception >>>>>>> is trapped. Have a peek at >>>>>>> https://issues.apache.org/jira/browse/AMQ-3236 and the associated >>>>>>> commits. We may be able to build on that. >>>>>>> >>>>>>> On 19 January 2012 05:58, Jason Dillon <ja...@planet57.com> wrote: >>>>>>>> Is there any easy way to get information about why a message had been >>>>>>>> sent to ActiveMQ.DLQ? >>>>>>>> >>>>>>>> I'm seeing a bunch of messages sent to a virtual topic (as indicated >>>>>>>> by OriginalDestination property while browsing the ActiveMQ.DLQ via >>>>>>>> visualvm, which end up in the DLQ. Really unsure why any message >>>>>>>> sent to a virtual topic would end up here. Shouldn't the virtual >>>>>>>> topic simply copy the message to all known client's and be done with >>>>>>>> it? >>>>>>>> >>>>>>>> More generally though, is there any way to include detail in the >>>>>>>> message when sent to the DLQ as to why it was sent there? >>>>>>>> >>>>>>>> --jason >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> http://fusesource.com >>>>>>> http://blog.garytully.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> http://fusesource.com >>>>> http://blog.garytully.com >>>> >>> >>> >>> >>> -- >>> http://fusesource.com >>> http://blog.garytully.com >> > -- http://fusesource.com http://blog.garytully.com
