[
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)
