Introduction to server suspension caused by application deadlock

Document directory

• Problem description
• Problem troubleshooting

Problem description

An inadvertent deadlock in the application code can cause a server to hang. for example, a situation in which thread1 is waiting for resource1 and is holding a lock on resource2, while thread2 needs resource2 and is holding the lock on resource1. neither thread can progress.

Problem troubleshooting

This application deadlock pattern shocould be used only after doing all the steps in{
Pagetracker. _ trackpageview ('/outbound/article/support.bea.com ');
} "Href =" http://support.bea.com/application_content/product_portlets/support_patterns/wls/GenericServerHangPattern.html "> generic server hangPattern. one indicator that this is an application deadlock problem is that thread dumps will show the threads are in the application methods. several thread dumps taken a few seconds apart will show that the threads are not progressing. troubleshooting this problem will involve reviewing the application code. there exists a thread analyzer tool at Bea {
Pagetracker. _ trackpageview ('/outbound/article/dev2dev.bea.com ');
} "Href =" http://dev2dev.bea.com/products/wlplatform81/articles/thread_dumps.jsp "> dev2dev which has proven useful in analysis of the thread dumps.

Quick Links

• Why does the problem occur?
• Known WebLogic Server issues
• External resources

 

Why does the problem occur?

Fundamentaly, this problem happens because the design and implementation of the application has introduced the possibility of deadlocks. these types of problems may only show up under heavy load. therefore, these applications often pass through QA testing and become problems in production.

Coding problems to look:

• Unnecessary use of synchronized Java classes, e.g., usingHashtable(Synchronized) versus the useHashMap(Unsynchronized)
• Application has a synchronized method that contains synchronized object method CILS. See example below.

  Import java. util. vector; <-vector is a synchronized Java class
  Public class employee {
  Vector names = new vector ();
  Employees (){
  Object object = new object ();
  Synchronized (object ){
  Names. Add ("Al ");
  Names. Add ("saganich ");
  }
  }
  Synchronized string getname (INT index ){
  String name = (string) names. elementat (INDEX );
  Return name;
  }

• Using synchronization around long running complex code.
• Threads are waiting on resources that will never become available.

Application Design

• The application uses up all of the configured number of threads. this can happen when an executing thread reaches a point where it must wait for work done by another thread to complete. the timing may be that the waited for method which this thread is trying to enter is long running. eventually, all the threads must reach this long running method. after running awhile, the application will find that the threads will be lined up waiting for this long running method. no new work can be introduced because the allocated number of threads is all used up. see example below.

  Import Java .....;
  Import Java .....;
  Public class myappmethods {
  Public String getname (string name ){
  String lastname = getlastname (name );
  Return lastname;
  }
  Public synchronized string getlastname (string name ){
  Do a DB lookup <---- takes mucho time to get a last name
  Return lastname;
  }

  If the database if very slow, the server can appear to be hung because the threads will line up trying to get access to the database and all the available threads cocould eventually be used up.

• The application running inside a WebLogic Server invokes a service on another WebLogic instance on a remote machine. the remote service invoked on the remote machine makes a call back to the first server. this sets up the opportunity for a deadlock on the first server especially under heavy load. the first server has an execution thread that is tied up waiting for an inbound response. this inbound response will require a thread from the same execute pool as the thread that is waiting to receive the response.

  If the first server is faster than the remote server, eventually all the threads in the execute pool will be exhausted by the server making outbound requests with fewer threads available for processing inbound responses. as the load grows, the number of outgoing requests that cannot complete their work grows while they wait for an inbound response to complete. below is an example of a thread inwaitForDataResponseImpl.javaMethod.

  "Executethread: '52' for queue: 'default'" daemon PRIO = 5 tid = 0 × 4b3e40b0 nid = 0 × 1170 waiting on monitor [0x4c74f000 .. 0x4c74fdbc]
  At java. Lang. Object. Wait (native method)
  At
  Weblogic. rjvm. responseimpl. waitfordata (responseimpl. Java: 72)

Top of page

Known WebLogic Server issues

WebLogic Server cannot detect deadlocked threads. some JVM's are able to do so. see external resources. there is a tool available for thread analysis as well as good information about thread dumps on BEA dev2dev.

Top of page

External resources

If you suspect a deadlock, it is helpful to go to the site of the JVM vendor to learn if there are clues provided for you in their thread dumps. if you are using JDK 1.3.1 you can add- XX:+JavaMonitorInStack TraceTo show locking more explicitly/builtin. here is an example of an hp jvm thread dump in which it is clearly marked that the Threads' state are waiting on monitor, and the monitor is identified. see example below.

"MSG 0-941667944865" (TID: 0 × 7b1a5ba0, sys_thread_t: 0 × 2a4290,
State:Waiting on monitor,
Thread_t: t @ 108, stack_base: 0 × 7a76e000, stack_size: 0 × 20000,
PC: 0xc01ea178, monitor =0 × 25334) PRIO = 8
Msgthread. Rest (compiled code)
Msgthread. Run (compiled code)
"MSG 3-941667944865" (TID: 0 × 7b1a5a80, sys_thread_t: 0 × 263278,
State:Waiting on monitor,
Thread_t: t @ 105, stack_base: 0 × 7a95d000, stack_size: 0 × 20000,
PC: 0xc01ea178, monitor =0 × 25334) PRIO = 8
Msgthread. Rest (compiled code)
Msgthread. Run (compiled code)
"MSG 5-941667944864" (TID: 0 × 7b1a5f08, sys_thread_t: 0 × 2c42d8,
State:Waiting onMonitor,
Thread_t: t @ 106, stack_base: 0 × 7aa65000, stack_size: 0 × 20000,
PC: 0xc01ea178, monitor =0 × 25334) PRIO = 8
Msgthread. Rest (compiled code)
Msgthread. Run (compiled code)

 

 

 

Note:

This article Reprinted from: http://www.hashei.me/2009/08/serverhang_application_deadlock.html