WAITING threads issue in wso2esb - activemq

Hi am working on wso2esb and using Active MQ for message queues.
After around 3 weeks of usage ESB server was hanging and with the help of JMX monitoring of ESB i found that they are a huge number of java threads are in WAITING state.
[EsbMonitoring] ***************** java Threads Attributes *********************
[EsbMonitoring] ThreadCount :8873
[EsbMonitoring] DaemonThreadCount :104
[EsbMonitoring] PeakThreadCount :8992
[EsbMonitoring] TotalStartedThreadCount :16086123
Initially when we start the ESB server they are around 560 threads
[EsbMonitoring] ***************** java Threads Attributes *********************
[EsbMonitoring] ThreadCount :592
[EsbMonitoring] DaemonThreadCount :78
[EsbMonitoring] PeakThreadCount :592
[EsbMonitoring] TotalStartedThreadCount :1510
I took thread dump with jstack of ESB server with
"ActiveMQ Connection Executor: tcp://my-desktop/127.0.1.1:61616#60595" prio=10 tid=0x00007fdb1c890800 nid=0x259e waiting on condition [0x00007fda951cd000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000070bdf6c18> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
"ActiveMQ Connection Executor: tcp://my-desktop/127.0.1.1:61616#60589" prio=10 tid=0x00007fdb1c8b7800 nid=0x259a waiting on condition [0x00007fda950cc000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000070be68c48> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
"ActiveMQ Connection Executor: tcp://my-desktop/127.0.1.1:61616#60590" prio=10 tid=0x00007fdb1c8ae800 nid=0x2597 waiting on condition [0x00007fda946c2000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000070be22c88> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
All this connections are closed in the active MQ side but ESB is still holding these threads and troubling ESB and making consumption high and after reaching curtain point it hangs . I need to restart the ESB server to solve this issue.
Firstly why are these connection are WAITING state forever and why ESB is not removing these kind of threads , Is there any way i can kill or destroy WAITING threads with out restarting ESB.
Any help would be appreciated.
Thank You..!

Another few questions
What version of WSO server ?
What is jvm version ?
Anyway, i assume you have pretty high load. I don't think i can reproduce it easy in short time. I had something similar with postgresql jdbc driver, connections were getting stuck after some time, and all connection in pool are got blocked. It was fixed just on jdbc driver update.
According http://mvnrepository.com/artifact/org.apache.activemq/activemq-broker version 5.8.0 quite old. It was released in 2013. There are some bug reports in activemq jira about connection leak. Few thing you can try.
Get latest version of library from jboss repository. Link you will find on same page as shown on picture underneath
Just be accurate with library dependencies. Update dependencies as well. List of jar files is underneath (It is from official documentation https://docs.wso2.com/display/ESB500/Configure+with+ActiveMQ)
activemq-broker-5.8.0.jar
activemq-client-5.8.0.jar
activemq-kahadb-store-5.8.0.jar
geronimo-jms_1.1_spec-1.1.1.jar
geronimo-j2ee-management_1.1_spec-1.0.1.jar
geronimo-jta_1.0.1B_spec-1.0.1.jar
hawtbuf-1.9.jar
slf4j-api-1.6.6.jar
activeio-core-3.1.4.jar (available in /lib/optional folder)
Another way just update to next release of activemq broker. ActiveMq mature project, so it less possible that in every new release it introduces massive amount of new features and break compatibility with previous version. If release notes doesn't state anything extra ordinary, try it, test it in test environment and make decision.

Related

Why WebLogic is stopping long running threads without throwing any Exception?

I have one Java application(Deployed on WebLogic) which I use for polling messages from Amazon FIFO but problem is that after running for a long time Whatever WebLogic is doing my thread behaves like a hibernated thread and my application stops polling messages without any exception.

Spring AMQP Consumer stopped receiving messages

I am using Spring AMQP.
My Consumer is stopped listening messages, however there is no exception in logs and I could not see any deadlock on thread dump.
I have two servers which are listening to 10 queues.
Everything was working fine when cache-mode of rabbit:connection-factory was 'CONNECTION'.
But when I changed it to 'CHANNEL' this issue started appearing frequently.
From the rabbitMQ UI console I can see there is one unacknowledged messages. (Acknowledge mode is 'AUTO').
It looks to me that client could not send acknowledgement back to the server.
I can see following in my thread dump
"" prio=10 tid=0x00007f5f3823c000 nid=0x5faa waiting on condition [0x00007f5f847e2000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007b83a5260> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.nextMessage(BlockingQueueConsumer.java:359)
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.doReceiveAndExecute(SimpleMessageListenerContainer.java:1000)
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.receiveAndExecute(SimpleMessageListenerContainer.java:989)
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.access$700(SimpleMessageListenerContainer.java:82)
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1103)
at java.lang.Thread.run(Thread.java:745)

how to stop activemq failover reconnect process

I use ActiveMQ Client 5.10.0 and failover protocol to connect to ActiveMQ Node,what I face now is that the failover reconnect process executes indefinitely if the ActiveMQ Node used in the failover uri breaks up,and another thread which is intended to stop the reconnect process just waits.
The thread dump which belongs to the mentioned stop thread above is as follows:
I can not post the whole thread dump here,please get from the link
could anyone help me?I am stuck in this problem for a long time!
Thanks very much!
By the way,I can not use any newer versions of ActiveMQ Client,because the target environment JDK is 1.6

Rabbitmq consumer shutting down repeatedly

I have configured a Dead Letter exchange with exponential back off policy. After making these changes, I have started getting an exception in the rabbitmq consumer getting shutdown repeatedly throwing the following exception:
Received shutdown signal for consumer tag=amq.ctag--Qn9jFNOd3vxhaHvEw8Nrw
com.rabbitmq.client.ShutdownSignalException: connection error
at com.rabbitmq.client.impl.AMQConnection.startShutdown(AMQConnection.java:715)
at com.rabbitmq.client.impl.AMQConnection.shutdown(AMQConnection.java:705)
at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:563)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException
at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:290)
at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:95)
at com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:139)
at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:532)
Can someone please give me some pointers regarding possible causes for this exception?
Thanks,
Shuchi
If you have changed your queue declarations in spring then make sure any queues that existed in Rabbit before the change have been deleted. RabbitMQ doesn't like it when you try to generate a queue with the same name with different parameters.

coldfusion server monitor jvm snapshots

one my server instances has started to go haywire in a multi-instance setup running adobe coldfusion 8.1 enterprise. the built in cf server monitor is throwing these alert snapshots constantly, however, this same box is running Fusion Reactor {http://www.fusion-reactor.com/fr/} and I can not figure out where they are coming from. anyone have any pointers or a good tool to decode these files?
full link: http://pastebin.com/42M2Nzpj
"CM Configuration Updater" prio=5 tid=82 WAITING
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:76)
at java.lang.Thread.run(Thread.java:662)
"AWT-Windows" prio=6 tid=299 RUNNABLE
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(WToolkit.java:293)
at java.lang.Thread.run(Thread.java:662)
"Signal Dispatcher" prio=9 tid=5 RUNNABLE
"Timer-3" prio=5 tid=67 TIMED_WAITING
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:509)
at java.util.TimerThread.run(Timer.java:462)
"scheduler-4" prio=5 tid=36 TIMED_WAITING
at java.lang.Object.wait(Native Method)
at jrunx.scheduler.SchedulerService.createRunnable(SchedulerService.java:188)
at jrunx.scheduler.ThreadPool$ThreadThrottle.createRunnable(ThreadPool.java:349)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:62)
"jrpp-145" prio=5 tid=11622 RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at jrun.servlet.jrpp.ProxyEndpoint.readFully(ProxyEndpoint.java:581)
at jrun.servlet.jrpp.ProxyEndpoint.readFully(ProxyEndpoint.java:573)
at jrun.servlet.jrpp.ProxyEndpoint.readInt(ProxyEndpoint.java:591)
at jrun.servlet.jrpp.ProxyEndpoint.readRequest(ProxyEndpoint.java:231)
at jrun.servlet.jrpp.JRunProxyService.swapRunnable(JRunProxyService.java:143)
at jrunx.scheduler.ThreadPool$ThreadThrottle.swapRunnable(ThreadPool.java:410)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:76)
I suspect you have an snapshot/alert set to collect a snapshot file when your JVM allocates more than 1000 megabytes of memory. This is probably not a great idea since under normal circumstances your Jvm might indeed allocate that much and recover with a GC. I would look at your alert/snapshot settings and adjust them.