JMS超时或TimeToLive

Question

I am fairly new to Java EE and JMS and am looking at doing an implementation using JMS.

Think of the following scenario:

Scenario

A user hits a servlet. A message is then put into a JMS server/Queue from this servlet. A response is then sent back to the user saying "Message Queued".

Option 1

The consumer/MDB receives the message from the JMS queue and processes it. This is normal operation and pretty standard.

Option 2

There is no consumer(for what ever reason) or the receiver is processing messages too slow. So what I would like is for the message in the queue to timeout. Once timed out, and email should be sent etc (email is just as an example).

Reading the API spec/Java EE 6 tutorial I have found in the QueuSender class

void send(Message message, int deliveryMode, int priority, long timeToLive) 

So by settings the timeToLive the message will be evicted from the queue. The problem is that the is no "interface/call back" to know that the message was evicted. It just disappears. Or am I mistaken?

Another approach I thought of was for a thread to monitor the queue and evict messages that are "expired" and pull them from the queue. But I don't think that is possible, is it?

Any light shed on this matter would greatly be appreciated.

Answer 1

You have to make use of some implementation specific functionality to fulfill your requirements. The JMS specification does neither define which action is taken with a timed out message, nor does it offer you any reasonable criteria selection when polling messages from a queue.

Most (if not all) JMS implementations do however offer the concept of DLQs (dead letter queues). If a message cannot be delivered to a regular consumer or times out, the JMS implementation will most likely be able to move the message to a DLQ, which is basically also a regular queue with its own listener.

So, if you set up two queues, Q1 and Q2 and configure Q2 as a DLQ for Q1, you would do your normal request processing in a listener on Q1 and implement an additional listener for Q2 to do the error/timeout handling.

Answer 2

Synchronous interaction over JMS might be of help to you either. Basicly on the client side you:

1. send a message with a correlation id and time-to-live
2. receive a message (usually in the same thread) using the same correlation id and specifying timeout (time-to-live == timeout so if you treat it dead, it's really dead)

On the other side, server:

1. on an incoming message must fetch the correlation id
2. specify that correlation id for a response while sending it back to the client. Of course server must be quick enough to fit the timeout/time-to-live threshold.

So on the client side you are always sure what's happend to the message that was sent.