Metrics not disposed for `GracefulShutdownInstrumentedPool`

[Ryan Scheidter]

When working with various ConnectionProvider/MetricRegistrar arrangements, I am able to verify deRegistration of Metrics when I dispose the provider, but only if I do not set anything for disposeTimeout. Once I add that, it loses the ability to deregister its Metrics.

Expected Behavior

ConnectionProvider Metrics should be deRegistered on dispose, regardless of disposeTimeout use.

Actual Behavior

When adding disposeTimeout to a ConnectionProvider, Metrics are no longer deRegistered when the ConnectionProvider is disposed

Steps to Reproduce

Can reproduce this problem with a tweak to an existing reactor-netty-core test:
Add to ConnectionProvider setup in PooledConnectionProviderDefaultMetricsTest.testConnectionPoolPendingAcquireSize:

.disposeTimeout(Duration.ofSeconds(1))

Possible Solution

In PooledConnectionProvider, I see that Metric cleanup is only performed in onErrorResume for the GracefulShutdownInstrumentedPool block:

reactor-netty/reactor-netty-core/src/main/java/reactor/netty/resources/PooledConnectionProvider.java

Lines 201 to 208 in dd0c42d

 if (pool instanceof GracefulShutdownInstrumentedPool) { 
     return ((GracefulShutdownInstrumentedPool<T>) pool) 
             .disposeGracefully(disposeTimeout) 
             .onErrorResume(t -> { 
                 log.error("Connection pool for [{}] didn't shut down gracefully", e.getKey(), t); 
                 return Mono.fromRunnable(() -> { 
                     if (poolFactory.registrar != null) { 
                         poolFactory.registrar.get().deRegisterMetrics(name, id, remoteAddress); 

whereas in the de facto else it is done unconditionally:

reactor-netty/reactor-netty-core/src/main/java/reactor/netty/resources/PooledConnectionProvider.java

Lines 220 to 223 in dd0c42d

 return pool.disposeLater().then( 
         Mono.<Void>fromRunnable(() -> { 
             if (poolFactory.registrar != null) { 
                 poolFactory.registrar.get().deRegisterMetrics(name, id, remoteAddress); 

Perhaps GracefulShutdownInstrumentedPool is supposed to perform the deRegistration on its own happy path, but I see nothing like that in its implementation. Without knowing how it was intended to work, not sure else I can glean...

Your Environment

• Reactor version(s) used: encountered in 1.1.18; reproduction was just done against main
• JVM version: 21
• OS and version: Windows 11

[Violeta Georgieva]

@rs017991 Thanks for the report and the reproducible example. I confirm that this is an issue and it will be fixed for the next release.