I am trying the scenario where one MessageProducer send many messages to a queue and set time to live for each message 5 seconds.

The expiry queue is set, and I expect after 5 seconds, all messages will be expired and moved to the expiry queue.This is happened, only if there is a MessageConsumer registered in the queue. Otherwise, the message will not expire until another consumer is set up for the queue.

is this a bug or the intended behaviour? I didn't find any documentation about this one, either on JBM documentation or JMS specification.

If this is intended behaviour, I will always put a dummy consumer as the solution of my problem ;)

What I did for JBoss MQ is schedule a timeout to occur for all expiring messages, similar to the scheduled message feature, which does the move/removal.

There are some scalability issues with doing that. Namely, every soon and not-so-soon expired message ID is kept in memory on a heap. It'd be better if the expiry date was kept as a separate column in the DB, and indexed, to assist in finding these messages without having to scan them all.

"genman" wrote:What I did for JBoss MQ is schedule a timeout to occur for all expiring messages, similar to the scheduled message feature, which does the move/removal.

There are some scalability issues with doing that. Namely, every soon and not-so-soon expired message ID is kept in memory on a heap. It'd be better if the expiry date was kept as a separate column in the DB, and indexed, to assist in finding these messages without having to scan them all.

Yes, I thought about this too.

It would be the easiest solution to implement, but as you mention too, I think it has scalability issues.

I am thinking along the lines of a expirer thread that periodically scans the queue

I've tried to register a dummy MessageConsumer as suggested by hendra_netm, but that doesn't seem to work. If I specify a matching selector, I'm receiving the messages that are meant to be expired. And if I specify a selector like "1 = 0", that doesn't seem to cause expiry to be checked.

What seems to work is to unregister and re-register the dummy consumer in regular intervals, but I wonder if there's a more elegant approach - any advice?

thanks for your reply. Unfortunately I can't get it to work, my messages seem to get stuck in the dummy MessageConsumer (even though I never call receive() on it). I tried with and without transactions and with all kinds of acknowledgement but no go...

I also don't see how it could work, doesn't a MessageConsumer have an internal buffer where it stores incoming messages - otherwise, how could MessageConsumer.receiveNoWait() ever return a message?

Maybe it's the way you set up your Connection or your Session, would you mind sending over your code?

Any chance that a JBM developer could chime in and let me briefly know whether this is actually meant to work? If it's meant to be that straightforward, why the discussion about queue reapers and scalability?

Any chance that a JBM developer could chime in and let me briefly know whether this is actually meant to work? If it's meant to be that straightforward, why the discussion about queue reapers and scalability?

Julian - could you explain in a bit more detail about what you are trying to achieve?

I have a request/response pattern between a client and a server communicating via JBM. The client sends a request and waits for the server to send the corresponding response. Since the request processing on the server side can take a while in some situations, I'd like the client to be able to cancel waiting for the response, and in this case I need the response delivered asynchronously (via e-mail) so that the user knows when the request has been processed.

It seems like the expiry queue feature would lend itself to implementing this: if the response doesn't get picked up by the client within a timeout of, say, 2 seconds, it expires and gets transferred to a second queue where it's picked up by a component that takes care of forwarding it by mail.

In this scenario it's not good enough for the message to be expired once an attempt is being made to pick it up on the original response queue (as there will possibly be no client listening for responses anytime soon). Instead, I need it to be moved once it's expiring.

Does this makes sense or would you consider this to be an abuse of the expiry feature? Do you see a way of implementing this in another way, maybe using temporary topics and a DLQ? (Right now I'm not using temporary topics for responses - instead I use a global response queue with a selector on the JMS_CorrelationID.) Unfortunately there's no way of selecting messages by age or that would be another way of handling this.

FWIW, I'm currently working around the issue by having a dummy consumer with a selector that never matches re-registering with the queue periodically, and with this workaround my system works fine. But it's obviously an ugly solution - even though the number of messages involved is negligible so there are no performance issues.

Does this makes sense or would you consider this to be an abuse of the expiry feature? Do you see a way of implementing this in another way, maybe using temporary topics and a DLQ? (Right now I'm not using temporary topics for responses - instead I use a global response queue with a selector on the JMS_CorrelationID.) Unfortunately there's no way of selecting messages by age or that would be another way of handling this.

The only guarantee a JMS compliant messaging system has to make with regard to message expiry is to ensure that you don't ever receive a message after the expiry time, if the expiry time has been specified.

JBM is fully compliant in that regard.

Anything to do with expiry queues etc, is beyond the scope of the spec.

In other words there's no guarantee that a particular JMS provider actually moves the message to the expiry queue actually at, or near to the desired expiry time.

You'll probably find that different providers do this in different ways, so designing your application to rely on this is probably a bad move.

In future versions of JBM we will probably implement some kind of expiry reaper thread that trawls the queues for expired messages and puts them on the expiry queue (if it is specified), but even with this the exact time they will get to the expiry queue is not really reliable, subject to how often the thread is scheduled to run, number of messages etc.