Hi Kristof, I think the approach to your problem is to develop a custom plugin that can track messages and their process times. There's some information on interceptor mechanism in ActiveMQ at these pages
http://activemq.apache.org/interceptors.html http://activemq.apache.org/developing-plugins.html 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 Tue, Jul 23, 2013 at 7:26 AM, kristof sajdak <kristof.saj...@gmail.com>wrote: > Hi, > > > I'm currently working on a project which uses AMQ to implement > fire-and-forget scenarios. > > > The producer sends a persistent message to the broker, a transactional > consumer which is configured with maximumRedeliveries = -1 processes the > message. > > If the listener attached to the consumer encounters an issue during > processing of the message, it will throw the exception up and the same > message is processed over and over again until success. > > When a message is not successfully processed within a certain interval x > (e.g. 1h), an alert should be issued to the operations department. When > the > same message does get processed successfully a bit later (e.g. 0,5h later) > the same alert should be closed. > > Our thinking was that we would periodically interrogate the broker to give > us 'the time spent in broker' of the oldest message for the various queues. > > > After having reviewed the documentation and done some quick tests, I'm not > sure how to get that information out in a reliable way using out-of-the-box > AMQ features. > > I read some articles which advise browsing the message on the queue via JMS > and looking at the JMSTimestamp to calculate the interval. However during > the time that the transactional consumer is retrying the message it's not > visible to the JMS browser at that time, is it ? > > In our opinion this approach could lead to some false negatives where the > jms browser doesn't see a message on a queue (as it is being processed), > hence doesn't issue the alert to operations. Depending on how the browser > and consumer threads line up we could see behaviour where the alert is > opened / closed / opened.... and so on. > > > Before looking at other alternatives I was hoping somebody could tell me > whether our assumptions are correct ? and if so what possible solutions > exist to deal with this issue. > > > Thanks > > > Kristof > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Reliably-calculate-time-spent-in-broker-tp4669606.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
