Thread Contention Issue Management

Detecting thread contention problems at runtime

The Admin4J thread contention monitor will notify administators of threading issues. A 'threading issue' is an observation that an active thread in the JVM is blocking other threads for longer than a given threshold.

Thread contention issues will often appear to application users s "slow" performance.

The thread contention monitor operates on a work/sleep cycle. You specify the contention threshold by controlling the length of the sleep interval and the number of threads that must be "blocked" to report the contention. This allows you to tune away false reports of contention issues.

Installing Thread Contention Monitoring

Note
If you followed the installation procedure detailed in the Getting Started section, there is no need to install the thread contention monitor separately. Only follow this procedure if you're not using the Admin4J Home Page Servlet.

Add the following servlet to your applications web.xml:

<servlet>
<servlet-name>Thread Monitor Startup Servlet </servlet-name>
<servlet-class>net.admin4j.ui.servlets.ThreadMonitorStartupServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
						

Note that there is no servlet mapping as there is nothing to display. The monitor is started with the initialization of the startup servlet.

The following configuration parameters are supported for the thread contention monitor. You specify these parameters as init parametes on the startup servlet:

Parameter Required Default Description
sleep.interval.millis N Default 30000 (30 sec) Amount of time in millis monitor will sleep between checks.
max.blocked.threads N 2 Number of blocked threads monitor will tolerate before notification.
notifier Y Defaults to default.notifier.class value in the Admin4J configuration. Handles admin notification. See documentation for the Notifier you're using for any additional configuration requirements. See Admin4J Notifiers section for more detail.

Monitoring thread contention in containers servicing multiple applications.

You only need one thread contention monitor per JVM. If the container you which to monitor services multiple applications, it's on necessary to install the thread monitor startup servlet in one of those applications.

How to respond to contention notifications

Some amount of contention is natural and unavoidable. A single isolated notification from time to time most likely warrants no action.

The notification will provide detail on the active thread and the threads that are being blocked.

Once you've located the blocking class and method, there are two basic strategies. First, find ways to minimize calls to the blocking class and method. Second, refactor the offending code so to minimize the synchronization that must occur.