Just a quick heads up. I added a periodic message expiry task[1] to a queue that makes use of the queue browser functionality. I will iterate over a snapshot of the messages in memory and/or page in some messages, to check their expiry and remove them as appropriate. This allows a message producer to use expiry to alleviate flow control or blocking behavior when there are slow on non existent consumers. There is a new statistic on a Destination that track the number of expires. All is good, but there are a few hairy bits w.r.t to concurrency. For example when an ack for an already expired message arrives, statistics need to be updated with care. The broker.isExpired() method now stamps the message with the original expiry time property so that it can gate expiry processing for a Queue and subsequent DLQ processing. Because of the additional a synchrony introduced by the expiry task, just checking message.isExpired() in broker code is not sufficient to initiate expiry. Rather broker.isExpired() should be used. broker.isExpired() will only return true once, where as message.isExpired() will remain true after the expiry event.
[1] https://issues.apache.org/activemq/browse/AMQ-1112 -- http://blog.garytully.com Open Source Integration http://fusesource.com
