Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.0.0-M21
-
None
Description
While using ApacheDS library to verify LDAP integration for Solr, I noticed a thread-leakage in the LdapServer code. Specifically the UnorderedThreadPoolExecutor added as part of LdapServer#start() method is not cleaned properly during the stop() method.
The carrotsearch randomized testing library in Solr reports following stack-trace as part of thread leak detection,
[junit4] 2> Dec 20, 2016 1:32:31 PM com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
[junit4] 2> SEVERE: 1 thread leaked from SUITE scope at org.apache.solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin:
[junit4] 2> 1) Thread[id=75, name=pool-4-thread-1, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithHadoopAuthPlugin]
[junit4] 2> at sun.misc.Unsafe.park(Native Method)
[junit4] 2> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4] 2> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[junit4] 2> at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
[junit4] 2> at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.fetchTask(UnorderedThreadPoolExecutor.java:462)
[junit4] 2> at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:414)
[junit4] 2> at java.lang.Thread.run(Thread.java:745)