[
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:
'AMQ224065: Failed to remove auto-created queue xyz'. 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:
_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)_
This did not happen in the previous version, as prior to
[ARTEMIS-4020|https://issues.apache.org/jira/browse/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 '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
nullcheck:
{{logger.debug("Unregistered meter: {}", removed != null ? removed.getId() :
"null");}}
> 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)
