0

If I am creating a bean which has a HTTPClient and annotate a method in this bean with @Schedule -> afterwars undeploy the app (e.g. tomcat or jboss) I am creating a Class Loader memory leak.

If I just delete the @Schedule annotation, it takes a bit of time after undeployment, but then the HttpClientImpl$SelectorManager is GCed.

I assume that the @Schedule mechanic keeps a soft link to the class and therefor the HTTPClient (which would normally allow it to be GCed), but the HttpClientImpl$SelectorManager does not understand this and keeps open?!

Anybody having similar trouble or has an idea on it?

MAT: (I have 3 @Schedule annotated classes / methods) enter image description here

(openjdk build 11.0.9+11-LTS, spring boot 2.4.4)

ben
  • 502
  • 4
  • 15
  • 1
    And the problem with that is? The class with `@Schedule` (the bean) will be a task in the queue for the `TaskExecutor`/`TaskScheduler` so the bean itself is also referenced. If that class uses the client that will ofcourse also stay alive (including all other instances). But I don't understand the problem you have, looks like you think you have a memory leak where you have none. – M. Deinum Mar 29 '21 at 17:51
  • Sorry, you are so right. I missed to mention that the screenshot above is after the undeployment. So the problem is that after undeploying, the above seen contextClassLoader are left behind and not gced – ben Mar 29 '21 at 18:05
  • Do you use a preconfigured `TaskScheduler`/`TaskExecutor` or using the default one? You are also using JBoss (judging from the screenshot). Looks like the tasks are scheduled but aren't cleaned and thus keeping references. – M. Deinum Mar 29 '21 at 18:11
  • Default one. Quickly checked with Tomcat -> it looks like I have the same problem, but would need to investigate further, if we think this is JBoss specific – ben Mar 29 '21 at 18:14
  • It looks like a rogue thread is holding on to stuff. What you could try is to use spring configured TaskExecutor with the HttpClientBuilder instead of letting it use a default. – M. Deinum Mar 29 '21 at 19:32
  • Possibly related https://stackoverflow.com/questions/63415935/using-net-http-httpclient-in-tomcat-causes-memory-leak – M. Deinum Mar 30 '21 at 05:23

1 Answers1

1

The HttpClientImpl$SelectorManager will terminate when it detects that all operations have terminated, and all references to the HttpClient have been released. However, there could be a small lag between the time all references are released, and the time that the SelectorManager thread notices it. By default, this could be up to 3 seconds.

If you are observing that the SelectorManager thread is still running - then it's either because:

  • there remain some strong references to the HttpClient,
  • some request is still in progress
  • the SelectorManager hasn't notice that it can terminate yet
daniel
  • 2,665
  • 1
  • 8
  • 18