activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SuoNayi <>
Subject Re:Reliably calculate time spent in broker
Date Sat, 27 Jul 2013 08:02:56 GMT
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" <> wrote:
>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
>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.
>View this message in context:
>Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message