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):
Read the whole article on our ADF Performance Monitor website
