Java thread dump: WAITING (on object monitor) - what is it waiting for?

Question

a similar question was asked java-thread-dump-waiting-on-object-monitor-line-not-followed-by-waiting-on , but there was no answer, so I will ask my question in the hope of receiving more information ...

In the next dump of the stream, I see that the stream is in the “on object monitor” state, but there is no line with a “wait” that will indicate that it is waiting. How to interpret this stack of threads and find out why (and what resource) this thread expects?

"eventTaskExecutor-50" prio=10 tid=0x0000000004117000 nid=0xd8dd in Object.wait() [0x00007f8f457ad000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:503) at com.tibco.tibjms.TibjmsxLink.sendRequest(TibjmsxLink.java:359) - locked <0x00007f98cbebe5d8> (a com.tibco.tibjms.TibjmsxResponse) at com.tibco.tibjms.TibjmsxSessionImp._confirmTransacted(TibjmsxSessionImp.java:2934) at com.tibco.tibjms.TibjmsxSessionImp._confirm(TibjmsxSessionImp.java:3333) - locked <0x00007f90101399b8> (a java.lang.Object) at com.tibco.tibjms.TibjmsxSessionImp._commit(TibjmsxSessionImp.java:2666) at com.tibco.tibjms.TibjmsxSessionImp.commit(TibjmsxSessionImp.java:4516) at org.springframework.jms.support.JmsUtils.commitIfNecessary(JmsUtils.java:217) at org.springframework.jms.listener.AbstractMessageListenerContainer.commitIfNecessary(AbstractMessageListenerContainer.java:577) at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:482) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1102) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:996) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Locked ownable synchronizers: - <0x00007f901011ca88> (a java.util.concurrent.ThreadPoolExecutor$Worker) 

This thread is one of the listener threads configured to receive messages from the Tibco bus.

thanks!

Marina

Answer 1

This is a feature of JSM HotSpot. When the stack is reset, the JVM restores the waiting object from the local variables of the method. This information is available for interpreted methods, but not for compiled native shells.

When Object.wait is executed often enough, it gets JIT compilation.
After that, there will be no “wait on” line in the stream dump.

• Since wait() must be called on a synchronized object, most often the wait object is the last locked object in the stack trace. In your case, this is

   - locked <0x00007f98cbebe5d8> (a com.tibco.tibjms.TibjmsxResponse) 

• To prevent Object.wait from JIT compiling (and so that status information is always available), use the following JVM option

   -XX:CompileCommand="exclude,java/lang/Object.wait" 

Answer 2

This stream is waiting for notification from another stream (the stream name is TCPLinkReader if you are viewing the full dump of the stream that you must find it), which is created by the TIBCO EMS client library.

The column shows that the Spring application is trying to complete the session. To fix the session, the EMS client needs to send some data to the server and wait for confirmation from the server that the session has been successfully completed or not.

TCPLinkReader thread is a dedicated thread that an EMS client uses to receive TCP packets (from server to client).

If you see this stream is long, there are 2 scenarios:

• Something is wrong on the server side of EMS, maybe hung

• there are some flaws in the client library that caused a deadlock, so the server sent a response, but the TCPLinkReader stream did not notify the caller stream.

Finally, post a full dump of the stream if the problem persists.