[jira] [Updated] (ARTEMIS-4698) MetricsManagers' remove method may cause a NullPointerException

["Justin Bertram (Jira)" <ji...@apache.org>]

     [ 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)