Sure, thanks for your attention. 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. Thanks, Julian View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090449#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...