I have been running the jbosstest suite off and on throughout the day against
a snapshot of main on linux to look into the issue people have reported concerning
running out of processes on linux. I am seeing a steady increase in threads from
32 for the baseline just after startup to 229 after one interation of the test suite to
329 after about 10 iterations of the test suite.
Clearly were leaking threads and it could be that the test code is not cleaning up
correctly, but I am seeing a large portion of the threads associated with JMS and I
question why this should be. Out of the 329 threads there are 266 JMS associated
threads. Here is the breakdown of the top active threads in terms of the
thread_count: last jboss code in the thread stack
JMS ASF Threads:
29: org.jboss.jms.asf.ThreadPool$Slot.waitWhileEmpty(ThreadPool.java:181)
SpySession Threads:
122: org.jbossmq.Mutex.waitLock
DistributedJMSServerOIL Threads:
39:
org.jbossmq.distributed.server.DistributedJMSServerOIL.run(DistributedJMSServerOIL.java:89)
SpyConnection Thread:
38: org.jbossmq.SpyConnection$1.run(SpyConnection.java:99)
ConnectionReceiverOIL Server
38:
org.jbossmq.distributed.server.ConnectionReceiverOIL.run(ConnectionReceiverOIL.java:110)
Passivator Threads:
24: org.jboss.util.WorkerQueue.getJobImpl
HyperSonic:
11: org.hsql.ServerConnection.run
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
