WebClient does not clean up underlying resources

[quaff]

I'm trying spring 5.2.0.RC1 and reactor-3.2.11 and reactor-netty-0.8.10, failed to clean up resources.

	@Bean
	public ReactorResourceFactory resourceFactory() {
		ReactorResourceFactory factory = new ReactorResourceFactory();
		factory.setUseGlobalResources(false);
		return factory;
	}

	@Bean
	public WebClient webClient() {
		ClientHttpConnector connector = new ReactorClientHttpConnector(resourceFactory(), client -> client);
		return WebClient.builder().clientConnector(connector).build();
	}

threads webflux-http-kqueue-n and elastic-evictor-1 and elastic-2 are not destroyed.

org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [webflux-http-kqueue-1] but has failed to stop it. This is very likely to create a memory leak. 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [webflux-http-kqueue-2] but has failed to stop it. This is very likely to create a memory leak.
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [elastic-evictor-1] but has failed to stop it. This is very likely to create a memory leak.
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [elastic-2] but has failed to stop it. This is very likely to create a memory leak.

Please run tests in attachment WebClientTest.zip.

[rstoyanchev]

Thanks for the sample. I verified this is not a regression and that the behavior is from the start in 5.1.0. It does clean up but it is triggered asynchronously. I added a 5 second delay and the threads were no longer there. I suppose we could change this to disposeLater().block() but the important point is that the cleanup does occur.

[quaff]

webflux-http-kqueue-* is destroyed after some delay, but elastic-evictor-1 and elastic-2 are never destroyed.
How to reduce the delay?

[rstoyanchev]

How to reduce the delay?

I don't think you can speed it up. It's how long it takes to shut down. At least in terms of Reactor Netty APIs I don't see anything else we can do from the Spring Framework side.

About the elastic-evictor-1 and elastic-evictor-2, those seem to be created by Reactor Core whenever the ElasticScheduler is used, which could be via Schedulers.elastic() for example. Are you using that anywhere in your code perhaps?

@smaldini any idea about the the evictor threads? I see some use of Schedulers.elastic() from PooledConnectionProvider in disposeLater(). Shouldn't such a method, intended for cleaning resources, avoid the use of a global scheduler that creates more threads?

[quaff]

@rstoyanchev I'm not using Schedulers.elastic(), It started by WebClient, that's all my code in test case.

[rstoyanchev]

I've created reactor/reactor-netty#846 for the elastic evictor threads but I'll leave this open since depending on the fix, we may have a follow-up change.

In addition we'll also make an improvement with #23631 to ensure that we wait until threads are stopped.

[bclozel]

Should this be targeted against our 5.2.X milestone?
The fix in reactor has been done in their 0.9.x generation (Dysprosium) and our own 5.1.x branch depends on Californium (reactor netty 0.8.x).

[quaff]

after commit ca2b2f5 , webflux-http-kqueue-* is destroyed after context closed, but there is a thread named globalEventExecutor-1-1 not destroyed immediately, should wait for 1 second.

[rstoyanchev]

after commit ca2b2f5 ...

@quaff please comment under #23631, which is the issue for that commit.

Should this be targeted against our 5.2.X milestone?

Either way it's a change for Reactor Netty to make to ensure the global elastic scheduler resources aren't used. I only kept this issue open in case their change required us to use a different API. However the change made is transparent for us so this issue can be closed. If it needs to work for 5.1.x (and Reactor Netty 0.8.x) then that change can only come from Reactor Netty.