[
https://issues.apache.org/jira/browse/ARTEMIS-5557?focusedWorklogId=978405&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-978405
]
ASF GitHub Bot logged work on ARTEMIS-5557:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 11/Aug/25 19:30
Start Date: 11/Aug/25 19:30
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #5856:
URL: https://github.com/apache/activemq-artemis/pull/5856#discussion_r2267816863
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/remoting/server/impl/RemotingServiceImpl.java:
##########
@@ -345,10 +338,14 @@ public synchronized void startAcceptors() throws
Exception {
if (isStarted()) {
for (Acceptor a : acceptors.values()) {
try {
- if (a instanceof NettyAcceptor acceptor &&
!acceptor.isAutoStart()) {
+ if (!a.isAutoStart()) {
continue;
}
a.start();
+
+ if (server.getMetricsManager() != null) {
+ a.registerMetrics(server.getMetricsManager());
Review Comment:
@jbertram if it's too difficult to unregister the metric.. I wouldn't bother
that much... as long as you don't re-register in case of a further start....
say.. stop / start / stop start...
or even then.. as long as i'ts documented. that's fine..
Of course if it can be fixed.. the better.
The case I was concerned was not registering at all in case of a late
start.. but even that would be a minor issue IMO.
Issue Time Tracking
-------------------
Worklog Id: (was: 978405)
Time Spent: 2h 20m (was: 2h 10m)
> Support Micrometer ExecutorService metrics
> ------------------------------------------
>
> Key: ARTEMIS-5557
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5557
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Justin Bertram
> Assignee: Justin Bertram
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Micrometer supports
> [metrics|https://docs.micrometer.io/micrometer/reference/reference/jvm.html]
> for instances of {{java.util.concurrent.ExecutorService}}. It would be
> helpful to expose these for the major thread pools used by the broker so that
> users can identify potential bottlenecks or other issues related to thread
> starvation.
--
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
