You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Erich Duda (JIRA)" <ji...@apache.org> on 2016/05/09 05:46:12 UTC
[jira] [Created] (ARTEMIS-518) Improvement of default thread
factory
Erich Duda created ARTEMIS-518:
----------------------------------
Summary: Improvement of default thread factory
Key: ARTEMIS-518
URL: https://issues.apache.org/jira/browse/ARTEMIS-518
Project: ActiveMQ Artemis
Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Erich Duda
I investigate test failures in the Artemis test suite and I see many
"Thread leaked" issues. From stack traces It is evident that leaking
threads arise from some thread pool and they are waiting for a job.
Problem is that I am not able to find which thread pool owns the
threads. When the default thread factory is used for creation of a
thread, the name and the stack trace of thread looks following.
{code}
Thread Thread[pool-4-thread-45,5,main] is still alive with the following stackTrace:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
{code}
I suggest to do not use the Java default thread factory but we should
create own default thread factory which will set up name of thread's
group in such way that we could find to which thread pool the thread
belongs. The thread dump could look like this:
{code}
Thread Thread[Thread-0
(org.apache.activemq.artemis.tests.unit.core.paging.impl.PagingStoreImplTest-32863545),5,org.apache.activemq.artemis.tests.unit.core.paging.impl.PagingStoreImplTest-32863545]
is still alive with the following stackTrace:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)