Identifying and Diagnosing a Thread Waiting Situation in the JVM

This section takes the help of the sapbusiness application yet again to demonstrate how the eG JVM Monitor quickly isolates waiting threads and identifies the root-cause for the thread waits.

Whenever a thread goes into waiting, the value of the Waiting threads measure reported by the jvm Threads test mapped to the jvm Internals layer gets incremented by 1 (see Figure 1).

Figure 1 : The Waiting threads

To know which threads are in waiting, click on the diagnosis icon corresponding to the Waiting threads measure in Figure 1. Figure 2 then appears listing all the threads that are currently in waiting.

Figure 2 : The detailed diagnosis of the Waiting threads measure

Of the threads listed in Figure 2, those that begin with http* are Tomcat’s java threads. For these threads to be in a waiting state is normal, and hence, these threads can be ignored. Only the SessionController thread indicated by Figure 2 is an application-specific thread. To know why this thread has been in waiting, you need to study the stack trace of the thread; for this, first scroll to the left of Figure 2. You will then be able to view the stack trace of the thread.

Figure 3 : Viewing the stack trace of the waiting thread

If you want to view the stack trace more clearly, click on the icon in Figure 3 or the Stack Trace label adjacent to the icon. Figure 4 then appears.

Figure 4 : The Thread Diagnosis window for Waiting threads

The left panel of Figure 4 lists all the waiting threads, with the thread that registered the highest waiting time being selected by default. Since we are interested in the user-defined SessionController thread, select it from the left panel. The right panel will then change as depicted by Figure 5 below.

Figure 5 : The stack trace for the SessionController thread

A close look at the stack trace reveals that the thread could have gone into the waiting mode while executing the code block starting at line 215 of the UserSession.java program file. To zero-in on the precise code that could have caused the thread to wait, open the UserSession.java file in an editor, and locate line 215 in it.

Figure 6 : The UserSession.java file

The code block starting at line 215 of Figure 6 explicitly puts the thread in the wait state until such time that the notify() method is called to change the wait state to a runnable state. This piece of code will have to be optimized to reduce or even completely eliminate the waiting period of the SessionController thread.

With that, we have demonstrated the eG JVM Monitor’s ability to detect waiting threads and lead you to the precise line of code that could have put the threads in a wait state.