Pooled Connection Provider does not appear to deregister metrics when pools are disposed by inactivity

[Nicholas Hagen]

The PooledConnectionProvider class has the ability to register and deregister metrics for a given id/socket address pair. When pools are created, the registration happens properly. However, when the inactivity scheduler occurs, the de-registration does not appear to occur. The disposeInactivePoolsInBackground method appears to only call Pool.dispose whereas other calls in that class such as disposeWhen or the overall provider disposeLater calls Pool.dispose but adds a subsequent handler to the disposal chain to de-register the metrics once disposed. I'm thinking the disposeInactivePoolsInBackground needs to either do something similar or maybe just call disposeWhen() with the socket address.

Expected Behavior

I am using Spring's WebClient which in turn uses Reactor Netty. I expect that metrics for a given address are registered and then de-registered. We use custom client-side load balancers, so the underlying socket address is constantly changing and dynamic. When pools do not de-register it results in a build-up overtime of metrics. I would expect that when a remote service leaves the pool and goes idle for the idle-time configuration that the de-registration should occur.

Actual Behavior

No de-registration appears to occur and the metrics live until the application is restarted.

Steps to Reproduce

Setup a Spring WebClient instance, setup a very low idle timeout or max lifetime limit and observe that PooledConnectionProvider.deRegisterDefaultMetrics is never invoked. However, registerDefaultMetrics is constantly invoked every idle timeout period.

I would expect that for every registration, a prior de-registration happens.

Possible Solution

Update the disposeInactivePoolsInBackground and any other path that removes pools to ensure they properly call deregister.

Your Environment

Spring WebClient, Mac M1

• Reactor version(s) used: 1.0.27 though it looks like the main branch appears to have same issue likely
• JVM version (java -version): 8
• OS and version (eg. uname -a): Mac OS X

[Violeta Georgieva]

@nicholashagen The fix is available in 1.0.39-SNAPSHOT and 1.1.13-SNAPSHOT. If you can test it, it would be great!