The ThreadLocal buffer is a known issue and is absolutely not a memory leak, although some web containers seem to think it is. It actually saves memory and reduces the load on the garbage collector, but the fact that web containers flag it is something we're aware of and we can look into and see if we can work around. But for now it's completely safe to ignore.
The connection pool should definitely shut down the health check thread when it is closed. There is a call to do it at the beginning of the method, and I'm not aware of any case in which that isn't actually done. I'll look into this, but if you can provide a simple reproducible test case in which the health check thread stays running after the pool is closed, then that would be helpful.
And if by "template connection", I assume you mean the connection you provide to the pool when creating it (as an alternative to using a server set). There isn't anything special about that connection versus other connections used in the pool, so it should be shut down just like all the others. If it's checked out of the pool when the pool is closed, then that connection will remain established until you attempt to release it back to the pool, but when it's released then it should be closed. Again, if you can provide a test case in which that isn't the case, then we can look into what's going on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't help but notice that an a hotdeployment I get the following logging:
Also Java VisualVM shows the threads staying behind: the template connection in the pool and a health check thread for the pool.
I'm using Springs DisposableBean which calls LDAPConnectionPool.close().
Is there a way to also shutdown the Health Check Thread?
The ThreadLocal buffer is a known issue and is absolutely not a memory leak, although some web containers seem to think it is. It actually saves memory and reduces the load on the garbage collector, but the fact that web containers flag it is something we're aware of and we can look into and see if we can work around. But for now it's completely safe to ignore.
The connection pool should definitely shut down the health check thread when it is closed. There is a call to do it at the beginning of the method, and I'm not aware of any case in which that isn't actually done. I'll look into this, but if you can provide a simple reproducible test case in which the health check thread stays running after the pool is closed, then that would be helpful.
And if by "template connection", I assume you mean the connection you provide to the pool when creating it (as an alternative to using a server set). There isn't anything special about that connection versus other connections used in the pool, so it should be shut down just like all the others. If it's checked out of the pool when the pool is closed, then that connection will remain established until you attempt to release it back to the pool, but when it's released then it should be closed. Again, if you can provide a test case in which that isn't the case, then we can look into what's going on.