Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
To: dev@activemq.apache.org
Cc: Miroslav Novak <mnovak@redhat.com>
From: Erich Duda <eduda@redhat.com>
Subject: Leaking threads in the Artemis test suite
Message-ID: <01cff3a3-55f6-099d-e054-bea37ff5d4b7@redhat.com>
Date: Fri, 6 May 2016 15:45:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------DF6EA4B472DBA9FABBB6F427"
archived-at: Fri, 06 May 2016 13:45:37 -0000

--------------DF6EA4B472DBA9FABBB6F427
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------DF6EA4B472DBA9FABBB6F427--