Reading the Thread Dumps

Best Practices for Developing Solutions > Monitoring ThingWorx Solutions > Monitoring and Troubleshooting Performance Issues > Slow Execution of Services > Using Thread Data to Monitor Slow Execution of Services > Reading the Thread Dumps

Each thread dump starts with a timestamp when the snapshot is collected:

Full thread dump taken at Thu Aug 1 07:19:59 EDT 2019

JVM thread dumps show the call stack involved in any server operations running on a specific thread. A call stack does not indicate an error on the server, though a frequent error also displays a call stack. A call stack shows in reverse order how specific methods were invoked. See the following example:

"http-nio-8080-exec-8" tid=0x114 in RUNNABLE
Blocked: 32[-1ms], Waited: 99[-1ms]
User CPU: 109ms
- synchronizer <0x4206a205> (a java.util.concurrent.ThreadPoolExecutor$Worker)
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(Unknown Source)
at com.thingworx.support.utilities.Stacktrace.dumpThreadInfo(Stacktrace.java:70)
at com.thingworx.support.utilities.Stacktrace.dumpAllStacks(Stacktrace.java:64)
- locked <0x4cdd9461> (a java.lang.Class)
at com.thingworx.support.utilities.Stacktrace.dumpAllStacks(Stacktrace.java:38)
- locked <0x4cdd9461> (a java.lang.Class)
at com.thingworx.support.utilities.SupportToolsTemplate.DumpAllThreads(SupportToolsTemplate.java:202)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.thingworx.common.processors.ReflectionProcessor.processService(ReflectionProcessor.java:261)
at com.thingworx.handlers.ReflectionServiceHandler.processService(ReflectionServiceHandler.java:50)
at com.thingworx.things.Thing.processServiceRequestDirect(Thing.java:7886)
at com.thingworx.things.Thing.processAPIServiceRequest(Thing.java:7824)
at com.thingworx.webservices.BaseService.handleInvoke(BaseService.java:3077)
at com.thingworx.webservices.BaseService.service(BaseService.java:356)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
…

In the call stack, the Support Subsystem is used to get thread information. The dumpAllStacks method invokes the dumpThreadInfo method that requests the thread information from the built-in Java platform.

The name of the service invoking these Java classes is generally listed below the call stack. In this case, the DumpAllThreads service is listed as part of the call stack. The processService method always invokes the custom services. Checking for services that are listed after processService in the call stack, enables you to get the thread on which a specific service is executed.

A thread has the following states:

• RUNNABLE—Good state. It indicates that the thread has all the resources it needs to perform the operations.

• BLOCKED—It indicates that the thread is waiting for an object in another thread before it can complete the operation.

• TIME_WAITING—It indicates that the thread is either waiting for a synchronizer to access a resource, or is waiting for some additional input (similar to WAITING state)

• WAITING—It indicates that threads are not doing any work. It is waiting for further input. This is the default normal state for 99% of the threads in a capture.

If you collect the output using the Java jstack command instead of the Support subsystem, many threads are shown in BLOCKED state. However, the threads are in TIME_WAITING state. This may be the default state for some types of threads. To avoid this, run the jstack command as sudo -u <tomcatUser> jstack <pid>.

Was this helpful?