[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695740#comment-14695740 ]
Manfred Baedke edited comment on SLING-4676 at 8/13/15 6:38 PM: ---------------------------------------------------------------- Thx [~cziegeler]. Since org.apache.sling.commons.threads.ThreadPoolConfig already features a method getKeepAliveTime() which is used to retrieve the time interval after which idle threads will be removed, my plan was to just add a max age constraint. The problem with this approach is that org.apache.sling.commons.threads.impl.DefaultThreadPool uses java.util.concurrent.ThreadPoolExecutor which actually maintains the pool and I didn't see a way to interfere since this stuff is at least package protected and there also is no suitable hook. I attached a provisional patch which adds the new config params, but doesn't do anything with the max age value yet. I see three possibilities: # I have a blind spot and there is a trivial solution # We write our own ThreadPoolExecutor (just mentioned for completeness) # We don't introduce a max age and use the Tomcat reflection hack instead. Opinions? was (Author: baedke): Thx [~cziegeler]. Since org.apache.sling.commons.threads.ThreadPoolConfig already features a method getKeepAliveTime() which is used to retrieve the time interval after which idle threads will be removed, my plan was to just add a max age constraint. The problem with this approach is that org.apache.sling.commons.threads.impl.DefaultThreadPool uses java.util.concurrent.ThreadPoolExecutor which actually maintains the pool and I didn't see a way to interfere since this stuff is at least package protected and there also is no suitable hook. I attached a provisional patch which adds the new config params, but doesn't do anything with the max age value yet. I see three possibilities: # I have a blind spot and there is a trivial solution # We write our own ThreadPoolExecutor (just mentioned for completeness) # We don't introduce a max age and use the Tomcat reflection hack instead. > Clean up threads or refresh threads when put back into the pool > --------------------------------------------------------------- > > Key: SLING-4676 > URL: https://issues.apache.org/jira/browse/SLING-4676 > Project: Sling > Issue Type: Improvement > Components: Commons > Reporter: Carsten Ziegeler > Fix For: Commons Threads 3.2.2 > > Attachments: sling-4676-provisional.patch > > > A thread from the pool might use thread locals which are - for whatever > reason - not cleaned up, when the thread is put back into the pool. > This can lead to memory leaks. > We should protect against this. > Unfortunately there is no official API to clean up thread locals. There are > solutions out there using reflection. > Another option is to simply discard the thread object after some time of > usage and use a fresh one. This needs to include thread objects staying in > the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)