Last week we had a new version of the ADF Performance Monitor available – version 9.5.

In this blog I will write on one of the new features; thread wait and thread blocked time of requests. Sometimes we cannot explain a poor performance, disruptions, hiccups. If we dive into the world of Java threads, we often can. It can be that some threads were waiting on some resources or were being blocked. Or if there was JVM garbage collection during the request (that froze all threads). We can see all this now in the monitor for each HTTP request in detail. We have much more insight into time gaps that were sometimes hard to explain before.

Thread States

In the Application Server HTTP Requests are being processed by Java threads. Sometimes these threads are doing nothing: they are in the waiting, timed waiting or blocked state:

• Waiting State: a thread that is waiting (indefinitely) for another thread to perform a particular action. It will need to wait till some other thread calls notify() or notifyAll() on the object. For example: under high load, if all datasources of the datasource connection pool are already occupied, the next thread will need to wait for one to become  available from the pool and will be in a waiting state. Or if an ApplicationModule needs to wait before an ApplicationModule becomes available from the ApplicationModule pool.
• Timed Waiting State: a thread is waiting for a specified waiting time. For example, Thread.sleep.
• Blocked State: a thread that is waiting for a monitor lock to enter a synchronized block/method. A Blocked state will occur whenever a thread tries to acquire lock on object and some other thread is already holding the lock. If program code or code in a (framework) library calls an (expensive) synchronized method, other threads will be blocked until the thread finishes.

Waiting/Timed Waiting State

The monitor shows for each HTTP request the waiting and times-waiting state together (in blue):

In this screenshot (Errors Overview) we see many requests that were in the waiting state for more than 20 seconds(!). They had to wait for a database connection to become available from the application server. Datasources are being shared in a pool. If all datasources are already being used under heavy load, and a new request for a datasource comes, this thread needs to wait until one becomes available for use. If this takes too long, the request will timeout, and throw an exception (this is what we see in the screenshot):

oracle.jbo.pool.ResourcePoolException: JBO-28102: A request timed out while waiting for a resource from the resource group hr.demo.model.service.HRServiceLocal to be returned.

Blocked State

In the following screenshot (HTTP Requests Overview) we can see some threads that were in the blocked state (red color), for more than 10 seconds(!):

Apparently, many times a blocked state was eventually started by a poll event, coming an ADF Faces component oracle.adf.RichPoll, with ID ‘p1‘.

JVM Garbage Collection

The monitor also shows now the JVM garbage collection time that took place during the request:

Conclusion

Now we can explain better why the process time of some requests took so long. This should be a trigger for further investigation. It helps tremendously if you know in what (type of) problem you have.

Free 7 Day Trial

We have also a free 7-day trial, you can request it on this website at our main page (adfpm.com).

We have also a whitepaper.

License

You can purchase a license of the ADF Performance Monitor at our order page.