[
https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-4676:
----------------------------------
Attachment: SLING-4676-jsedding-1.patch
I attached a patch that allows pro-active expiry of threads in a small
extension of {{ThreadPoolExecutor}}. The patch is meant to gather feedback and
therefore does not yet hook the implementation into Sling's
{{DefaultThreadPool}}.
The mechanism is based on two observations:
- Threads in which an exception is thrown are replaced by {{ThreadPoolExecutor}}
- Throwing an exception in the {{ThreadPoolExecutor#afterExecute()}} method,
designed to be overridden, does not influence the outcome of an execution.
The implementation I suggest uses these two observations to throw an exception
from {{afterExecute()}} when a thread has expired.
The {{beforeExecute()}} method is used to record the first time a thread is
used and it also hooks up an {{UncaughtExceptionHandler}} in order to swallow
the control-flow exception thrown by {{afterExecute()}}. Handling of all other
exceptions is delegated to the original handler.
This approach can be considered hacky. However, the only other option I could
think of was to decorate a pair of {{ThreadPoolExecutors}} and shift the work
from one to the other periodically to allow killing all threads in the inactive
pool. To me such an implementation seems to be a lot more complex, however.
[~cziegeler], [~baedke], I would appreciate hearing if you have any doubts
before I finish off the integration and commit the changes. Thanks!
> 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-jsedding-1.patch, 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)
