[
https://issues.apache.org/jira/browse/ARTEMIS-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936592#comment-17936592
]
Justin Bertram commented on ARTEMIS-5350:
-----------------------------------------
bq. We want to generate an alert if a message has not been processed after, for
example, 30 minutes... We have messages in the queue, the consumer is
processing them, and regularly acknowledges messages.
Can you elaborate on the use-case where there is a message at the head of the
queue that isn't being acknowledged while messages "behind it" regularly are
being acknowledged? My guess is that this is related to selectors. Is that
correct? If so, would more robust consumer metrics help? I'm considering a new
option to enable consumer metrics on a per-address basis that would export
metrics for consumers similar to what is available in the web console (e.g.
"Remote Address," "Messages in Transit," "Last Acknowledged Time," etc.).
bq. Could you please elaborate on the impact of the brief queue locking?
Locking the queue means that other threads cannot read from or write to it. In
short, all operations on the queue must stop.
bq. Additionally, is this information already exported as an MBean, and if so,
does it have the same effect?
Yes and yes.
This is, in part, why efforts have been made to limit the exposure here. For
example, the new web console won't poll the JMX MBeans as often now that the
"tree" view has been removed. Also, recently new management methods named
{{peekFirstMessageAsJSON}} and {{peekFirstScheduledMessageAsJSON}} were added.
These methods are _operations_ rather than _attributes_ so the underlying logic
won't be executed implicitly when a JMX tool polls the MBean. In the next major
release (i.e. 3.0) the "firstMessage" attributes will be removed.
To be clear, this locking isn't a problem for most use-cases. The problems
start cropping up once load increases at which point the locking negatively
impacts how far the broker can scale. It eventually becomes pathological such
that the more you observe the system the worse it performs. This is something
we definitely want to avoid.
> Expose First Message Age via Metrics
> ------------------------------------
>
> Key: ARTEMIS-5350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5350
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
> Reporter: Dominik
> Priority: Major
>
> The "FirstMessageAge" which is available via the management interfaces should
> be exposed via the metrics subsystem so it can be consumed & visualized and
> also so that folks can create alerts based on it.
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
