[
https://issues.apache.org/jira/browse/SLING-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962589#comment-15962589
]
Julian Sedding commented on SLING-6261:
---------------------------------------
I think the approach looks pretty good and is definitely an improvement.
However, I have not thoroughly reviewed the code.
We need to consider what happens on other JVMs than Oracle's, however. I don't
know if ThreadLocals are implemented the same way and accessing the (internal)
fields via reflection works. IMHO this requires us to:
- make sure the ThreadLocal cleaning functionality is disabled if the fields
cannot be found via reflection (I think an "info" level log message at startup
to indicate this situation would be appropriate)
- (possibly later) enhance the code to cover other JVMs
> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --------------------------------------------------------------------------
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
> Issue Type: Improvement
> Components: Commons
> Affects Versions: Commons Threads 3.2.6
> Reporter: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a
> {{RuntimeException}} with message "Kill old thread" is used in
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a
> suspension of the thread when debugging with Eclipse (as since Neon JDT will
> suspend the thread on all uncaught exceptions). More information is available
> in
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
> There should be a different mechanism to kill the thread than an uncaught
> exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
