activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erich Duda <ed...@redhat.com>
Subject Re: Leaking threads in the Artemis test suite
Date Mon, 09 May 2016 05:54:19 GMT
Justin, thank you for your respond. I have created the JIRA [1] and PR [2].

Erich

[1] https://issues.apache.org/jira/browse/ARTEMIS-518
[2] https://github.com/apache/activemq-artemis/pull/512


Dňa 06.05.2016 o 15:59 Justin Bertram napísal(a):
> That seems reasonable to me.  Open a JIRA and send a PR.
>
>
> Justin
>
> ----- Original Message -----
> From: "Erich Duda" <eduda@redhat.com>
> To: dev@activemq.apache.org
> Cc: "Miroslav Novak" <mnovak@redhat.com>
> Sent: Friday, May 6, 2016 8:45:28 AM
> Subject: Leaking threads in the Artemis test suite
>
> Hi guys,
> 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.
>
> 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)
>
> 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.
>
> I have already created such thread factory and reconfigure all thread
> pools to use it. You can review my changes in the commit [1]. The
> default thread factory is implemented in the ActiveMQThreadFactory class
> [2]. The name and the stack trace of the thread created by this thread
> factory looks following.
>
> 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)
>
> I ran full test suite and it seems that this changes did not break
> anything. What do you think about it? Would it be possible to merge the
> commit?
>
> Thank you!
>
> Erich
>
> [1]
> https://github.com/dudaerich/activemq-artemis/commit/b1e48589acd9c1febd62105cc23fa4c04d673a5b
> [2]
> https://github.com/dudaerich/activemq-artemis/blob/b1e48589acd9c1febd62105cc23fa4c04d673a5b/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/ActiveMQThreadFactory.java
>


Mime
View raw message