JMS message re-delivery delay
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.
Answer
JMS 2.0 Specification defines a "Delivery delay" where client can specify a delivery delay value in milliseconds for each message it sends. This value defines a message delivery time which is the sum of the message’s delivery delay and the GMT it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed).
A message's delivery time is the earliest time when a JMS provider may make the message visible on the target destination and available for delivery to consumers. The provider must not deliver messages before the delivery time has been reached.
This feature is quite handy for the scenario described above.