I have a JMS client that can ssh to remote systems upon receiving a message (and do various things there – not relevant to the question). It is possible that hundreds of such messages will arrive in a short period of time which need to be processed ASAP.
However, it is also possible that certain remote systems are not available when the message is received, so they should be postponed until later (eg. 1 hour or so). The best solution would be to put the message back to the queue with some “delay” value set, which will tell the JMS broker not to try to deliver the message again within an hour.
What is not OK: sleep in the receiving thread and wake up an hour later. Since the message consumer pool is limited (eg. 8 connections available) having 8 non-reachable systems would block the whole processing unnecessarily, which is unacceptable.
I didn’t find a setting for either the message or the queue itself for such a “delay” value, does it exist?
A workaround solution is to use a second queue for storing messages to unreachable systems, and process these separately. But it is not a very elegant solution, and requires additional programming. Perhaps there is a better way.
This is not possible through the JMS API prior to JMS 2.0. As a general rule, message transports are optimized to deliver messages as fast as possible and lack schedulers to hold a message for redelivery at some arbitrary interval. Assuming there is a transport provider that does have such functionality, anything you write would then be bound to that transport provider because, although the code might be JMS-compliant, the app itself would rely on this vendor-specific behavior.
See @Shashi’s answer for an answer that applies to versions of MQ that support JMS 2.0.