We are using the SMPP component to integrate our messaging platform with SMS-Cs. I have found that we occasionally get a massive rise in number of threads in the system.
It would go from around 300 threads used with a steady rise up to over 5,000 threads. Looking at when this occurs I think it is linked to losing a connection with the SMS-C and therefore it tries to reconnect. While the connection is down it continues to increase the thread count and then when the connection is re-established it flat lines again and stays at that number (ie. over 5,000). I am wondering whether it is linked to the SMPPSession in jsmpp and the fact that each time we try to reconnect we establish a new session. The previous session is closed, but the session contains a PDUReaderWorker that has a thread pool (with a default size of 3). I suspect the threads in this pool are not being released when the session is closed. Has anyone had this problem or has knowledge about whether my suspicions are correct. In JConsole I have alot of threads that look like this. Name: pool-1329-thread-1 State: WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@13e9a32 Total blocked: 0 Total waited: 1 Stack trace: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) java.lang.Thread.run(Thread.java:679) -- View this message in context: http://camel.465427.n5.nabble.com/Unreleased-thread-possible-in-SMPP-component-tp4922901p4922901.html Sent from the Camel - Users mailing list archive at Nabble.com.
