activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "clebert suconic (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (ARTEMIS-518) Improvement of default thread factory
Date Thu, 03 Nov 2016 20:40:04 GMT

     [ https://issues.apache.org/jira/browse/ARTEMIS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

clebert suconic closed ARTEMIS-518.
-----------------------------------

> 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
>             Fix For: 1.3.0
>
>
> 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)

Mime
View raw message