[
https://issues.apache.org/jira/browse/SLING-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reopened SLING-6261:
------------------------------------
It seems the previous commit does not work under all circumstances. Sometimes
the following NPE within the IT can be observed (which may happen at runtime as
well)
{code}
Running
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest
Exception in thread "pool-9-thread-1" java.lang.NullPointerException
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.changed(ThreadLocalCleaner.java:140)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.diff(ThreadLocalCleaner.java:104)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.cleanup(ThreadLocalCleaner.java:79)
at
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.afterExecute(ThreadPoolExecutorCleaningThreadLocals.java:63)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1150)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Exception in thread "pool-9-thread-2" java.lang.NullPointerException
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.changed(ThreadLocalCleaner.java:140)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.diff(ThreadLocalCleaner.java:104)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.cleanup(ThreadLocalCleaner.java:79)
at
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.afterExecute(ThreadPoolExecutorCleaningThreadLocals.java:63)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1150)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.192 sec <<<
FAILURE! - in
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest
testThreadLocalBeingCleanedUp(org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest)
Time elapsed: 0.046 sec <<< FAILURE!
org.mockito.exceptions.verification.WantedButNotInvoked:
Wanted but not invoked:
listener.changed(
ADDED,
<any>,
java.lang.ThreadLocal@3632be31,
"test"
);
-> at
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest.testThreadLocalBeingCleanedUp(ThreadPoolExecutorCleaningThreadLocalsTest.java:60)
Actually, there were zero interactions with this mock.
at
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest.testThreadLocalBeingCleanedUp(ThreadPoolExecutorCleaningThreadLocalsTest.java:60)
Results :
Failed tests:
ThreadPoolExecutorCleaningThreadLocalsTest.testThreadLocalBeingCleanedUp:60
Wanted but not invoked:
listener.changed(
ADDED,
<any>,
java.lang.ThreadLocal@3632be31,
"test"
);
-> at
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocalsTest.testThreadLocalBeingCleanedUp(ThreadPoolExecutorCleaningThreadLocalsTest.java:60)
Actually, there were zero interactions with this mock.
Tests run: 6, Failures: 1, Errors: 0, Skipped: 0
{code}
To me it seems that the
{{org.apache.sling.commons.threads.impl.ThreadLocalCleaner.diff}} method does
not properly check for {{null}} Entries within the table field (which may
happen, because those are WeakReferences themselfes and get invalidated
together with the key = ThreadLocal variable from the Thread class)
> 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
> Assignee: 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.4.14#64029)
