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