Metrics not disposed for GracefulShutdownInstrumentedPool

[rs017991]

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

[violetagg]

@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.