[jira] [Updated] (SLING-4676) Clean up threads or refresh threads when put back into the pool

["Julian Sedding (JIRA)" <ji...@apache.org>]

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