If queue browser is created before consumers, the browser should be able to see those pending messages that are dispatched to consumers while not acked by consumers.
At 2013-07-24 16:41:09,"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.
