activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <>
Subject Re: Reliably calculate time spent in broker
Date Wed, 24 Jul 2013 21:39:01 GMT
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

Dejan Bosanac
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: @dejanb
ActiveMQ in Action:

On Tue, Jul 23, 2013 at 7:26 AM, kristof sajdak <>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:
> Sent from the ActiveMQ - User mailing list archive at

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