Possible thread leak

[boyanl]

There seem to be 2 cases of threads that aren't properly terminated, which causes memory leaks when the app is re-deployed, e.g. on Tomcat

In WebSecurityConfig:

• there's a Timer object created (for fetching metadata over HTTP), but it's not destroyed when the bean is destroyed. (thus its TimerThread remains alive)
• MultiThreadedHttpConnectionManager has a static ReferenceQueueThread instance, which also remains alive.

Calling .cancel() + .purge() on the Timer instance, and calling MultiThreadedHttpConnectionManager.shutdownAll() when the config is destroyed seems to solve the issue. (It's not a big deal for the sample app, but I'm guessing that someone else might also use it as a template and run into the same issue)

Note: Using MultiThreadedHttpConnectionManager.shutdownAll() seems a bit suspect, as it shuts down all instances in the current JVM, but it's the only way to terminate the ReferenceQueueThread that I mentioned

[vdenotaris]

Hi @boyanl. You are perfectly right: I was actually already aware of this issue, but it is definitely time to fix it. I will do it within the next release.

Thanks for your input, Cheers, V.

[gimerstedt]

this should be a non-issue when running it as a standalone fat jar, as opposed to using an application server, correct?

[boyanl]

Yeah, shouldn't be an issue with a fat jar