"mpr_prabhu" wrote : | However would consider this as a defect in JBM as I expect it to handle it more gracefully and clean up expired messages or ensure these do not affect new messages | The JMS spec only requires that expired messages are never received by a consumer. It does not require that expired messages are actively expired from the queue before consumption nor does the JMS spec require expiry queues. Having said that, JBM 2.0 will implement active message expiry from queues before consumption, probably with some kind of reaper thread. However, even with a reaper thread, there can be no hard guarantees of timely expiry before consumption - that would be very hard to implement. The reaper thread will take a finite time to scan the queue, and during this time there would still be the possibility of expired message buildup if you send messages fast enough. One thing I have thought about, is a new special queue type that may be useful with time limited messages (e.g. stock prices). With the special queue type, you send the message with a special header, say, JBM_TIME_LIMITED_ID, and set the value to, say, your stick ticker code for the instrument, e.g. RHT. Then the queue itself makes sure it only maintains the latest version of message with a specific value of that header, and discards earlier ones. E.g. if I send Message A - MSFT price Message B - MSFT price Message C - RHT price Message D - IBM price Message E - RHT price Message F - RHT price. Then I start consuming from the queue I will only receive messages: B, D, F - i.e. the latest prices for each stock. Just an idea, but I think would be a nice feature and useful for some applications. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135134#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...