[
https://issues.apache.org/jira/browse/ARTEMIS-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4698:
------------------------------------
Description:
I recently switched from Artemis-server 2.19.1 to 2.31.1. From this point, I
have been experiencing a lot the following errors:
{noformat}
AMQ224065: Failed to remove auto-created queue xyz{noformat}
The stack trace shows that this consistenly happens in the {{remove}} call of
the {{MetricsManager}}. More specifically, the {{logger.debug}} statement which
uses the {{removed}} variable:
{noformat}
java.lang.NullPointerException: Cannot invoke
"io.micrometer.core.instrument.Meter.getId()" because "removed" is null
at
org.apache.activemq.artemis.core.server.metrics.MetricsManager.remove(MetricsManager.java:167){noformat}
This did not happen in the previous version, as prior to ARTEMIS-4020 the log
statement was conditional based on whether debug logging was enabled.
While the issue at hand may be caused by my application (un)registering
additional metrics on some queues, I feel the {{MeterRegistry}} should include
a null-check for the value of removed, as by the JavaDoc of Micrometers'
MeterRegistry, the meterRegistry.remove will return:
bq. The removed meter, or null if the provided meter is not currently
registered.
Also, as a {{null}} from the {{MeterRegistry}} means that the metric no longer
exists, as this is a remove call that should not be a blocking issue.
I currently work around the issue using a class overload with an inline null
check:
{code:java}
logger.debug("Unregistered meter: {}", removed != null ? removed.getId() :
"null");{code}
was:
I recently switched from Artemis-server 2.19.1 to 2.31.1. From this point, I
have been experiencing a lot the following errors:
{noformat}
AMQ224065: Failed to remove auto-created queue xyz{noformat}
The stack trace shows that this consistenly happens in the {{remove}} call of
the {{MetricsManager}}. More specifically, the {{logger.debug}} statement which
uses the {{removed}} variable:
{noformat}
java.lang.NullPointerException: Cannot invoke
"io.micrometer.core.instrument.Meter.getId()" because "removed" is null at
org.apache.activemq.artemis.core.server.metrics.MetricsManager.remove(MetricsManager.java:167){noformat}
This did not happen in the previous version, as prior to ARTEMIS-4020 the log
statement was conditional based on whether debug logging was enabled.
While the issue at hand may be caused by my application (un)registering
additional metrics on some queues, I feel the {{MeterRegistry}} should include
a null-check for the value of removed, as by the JavaDoc of Micrometers'
MeterRegistry, the meterRegistry.remove will return:
bq. The removed meter, or null if the provided meter is not currently
registered.
Also, as a {{null}} from the {{MeterRegistry}} means that the metric no longer
exists, as this is a remove call that should not be a blocking issue.
I currently work around the issue using a class overload with an inline null
check:
{code:java}
logger.debug("Unregistered meter: {}", removed != null ? removed.getId() :
"null");{code}
> MetricsManagers' remove method may cause a NullPointerException
> ----------------------------------------------------------------
>
> Key: ARTEMIS-4698
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4698
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.27.0, 2.27.1, 2.28.0, 2.29.0, 2.30.0, 2.31.0, 2.31.1,
> 2.31.2, 2.32.0, 2.33.0
> Reporter: Jelle Smits
> Priority: Minor
>
> I recently switched from Artemis-server 2.19.1 to 2.31.1. From this point, I
> have been experiencing a lot the following errors:
> {noformat}
> AMQ224065: Failed to remove auto-created queue xyz{noformat}
> The stack trace shows that this consistenly happens in the {{remove}} call of
> the {{MetricsManager}}. More specifically, the {{logger.debug}} statement
> which uses the {{removed}} variable:
> {noformat}
> java.lang.NullPointerException: Cannot invoke
> "io.micrometer.core.instrument.Meter.getId()" because "removed" is null
> at
> org.apache.activemq.artemis.core.server.metrics.MetricsManager.remove(MetricsManager.java:167){noformat}
> This did not happen in the previous version, as prior to ARTEMIS-4020 the log
> statement was conditional based on whether debug logging was enabled.
> While the issue at hand may be caused by my application (un)registering
> additional metrics on some queues, I feel the {{MeterRegistry}} should
> include a null-check for the value of removed, as by the JavaDoc of
> Micrometers' MeterRegistry, the meterRegistry.remove will return:
> bq. The removed meter, or null if the provided meter is not currently
> registered.
> Also, as a {{null}} from the {{MeterRegistry}} means that the metric no
> longer exists, as this is a remove call that should not be a blocking issue.
> I currently work around the issue using a class overload with an inline null
> check:
> {code:java}
> logger.debug("Unregistered meter: {}", removed != null ? removed.getId() :
> "null");{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
