Thanks @Aaron for the detailed explanation. I was also thinking about exact same solution to either have a longer timeout or have the messages persisted for sometime on the client and use it to reject the message if it comes back via DMQ.
This is because unfortunately we have a situation where we have to have the DMQ being listened by another application which again routes the same message to the queue for re-try scenarios and to have control over the retry and other features.
The behaviour on QPID is the same w.r.t dispatching it to DMQ, but what differs is that it can filter out messages which are expired during transit by enabling the property jms.localMessageExpiry . **** This way the expired message is not consumed by the application and the only mechanism is that it would be consumed by the application bound to DMQ. I did not see such capability with JCSMP. Hope this clarifies what I meant, sorry that I was not clear earlier.
Best Regards,
Karthik