periodic message expiry task

[Gary Tully <ga...@gmail.com>]

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