On a second thought, why you just don't just set expiry on the messages (e.g. 1h) which will move them to the separate queue (dlq) and use advisory to create alert. You can then close the alert later when you process a message from dlq.
Regards -- Dejan Bosanac ---------------------- Red Hat, Inc. FuseSource is now part of Red Hat dbosa...@redhat.com Twitter: @dejanb Blog: http://sensatic.net ActiveMQ in Action: http://www.manning.com/snyder/ On Fri, Jul 26, 2013 at 12:06 AM, kristof sajdak <kristof.saj...@gmail.com>wrote: > Hi Dejan, > > Thanks for your reply. > > I had a look at the plugin feature and I agree it could be a viable > solution. > However it does seem that I have to take extra considerations into account > to make the solution robust. > > If I keep the message timings in memory similar to the other plugin > implementations, and the broker crashes or shuts down gracefully they are > gone from memory when the broker comes up again. > > My assumption is that I could deal with this by re-reading the messages > from > the queue and populate the memory stats at broker startup time but before > any remote consumer becomes active. > > Could you let me know whether you think this is correct ? > > If so I'm also wondering how to go about implementing the interceptor, can > I > use the regular ActiveMQConnectionFactory, or do I use something inside the > BrokerFilter api to re-read the messages from the queue ? > > Regards, > > Kristof > > > > > > > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Reliably-calculate-time-spent-in-broker-tp4669606p4669759.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
