Troubleshooting
Problem
The SystemOut.log contains a WSVR0605W message, also called a hung thread message. A javacore, or thread dump on Solaris and HP-UX, is needed in order to determine how to resolve the potentially hung threads.
Symptom
WSVR0605W: Thread <threadname> has been active for <time> and may be hung. There are <totalthreads> in total in the server that may be hung.
Cause
WebSphere Application Server attempts to report potentially hung threads using the hung thread detector. Depending on how the hung thread detector policy is configured, a thread running for a certain interval (default 10 minutes) might be reported as hung and a WSVR0605W message is printed in the SystemOut.log file:
WSVR0605W: Thread <threadname> has been active for <time> and may be hung. There are <totalthreads> in total in the server that may be hung.
NOTE: Depending on the application, it might be normal for certain threads to be running for long periods of time and these could be falsely reported as hung threads.
WSVR0605W: Thread <threadname> has been active for <time> and may be hung. There are <totalthreads> in total in the server that may be hung.
By setting a WebSphere custom property, the hung thread detector will automatically generate a javacore, or print a thread dump in the native_stdout.log for Solaris and HP-UX, when a WSVR0605W message is written out to the SystemOut.log file. Javacores/thread dumps are needed for determining what code is running in the potentially hung thread, if the reported hung thread is blocked by other threads, and/or if bottlenecks exist in the JVM.
NOTE: Depending on the application, it might be normal for certain threads to be running for long periods of time and these could be falsely reported as hung threads.
Environment
The com.ibm.websphere.threadmonitor.dump.java property was enabled in WebSphere Application Server V6.0.2.29, 6.1.0.19, 7.0, 8.0, 8.5 and later.
Resolving The Problem
Set the com.ibm.websphere.threadmonitor.dump.java property to true:
Application Servers:
NOTE: Starting in WebSphere Application Server 7.0.0.25, 8.0, 8.5, and later you can now specify an integer in the 'Value' field of this custom property, making it possible to limit the number of javacores/thread dumps produced. For example, setting "10" as the value, it will only generate javacores on the first 10 hung thread messages reported.
Application Servers:
- From the administrative console, click Servers > Application Servers > server_name.
- Under Server Infrastructure, click Administration > Custom Properties.
- Click New and add the following property:
Name: com.ibm.websphere.threadmonitor.dump.java
Value: true
- Click Apply.
- Click OK and save the configuration changes.
- Restart the Application Server for the changes to take effect.
- From the administrative console, click System Administration > Node Agents > nodeagent.
- Under Additional Properties, click Administration Services
- Under Additional Properties, click Custom Properties
- Click New and add the following property:
Name: com.ibm.websphere.threadmonitor.dump.java
Value: true
- Click Apply.
- Click OK and save the configuration changes.
- Restart the Node Agent for the changes to take effect.
NOTE: Starting in WebSphere Application Server 7.0.0.25, 8.0, 8.5, and later you can now specify an integer in the 'Value' field of this custom property, making it possible to limit the number of javacores/thread dumps produced. For example, setting "10" as the value, it will only generate javacores on the first 10 hung thread messages reported.
[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Hangs\/Performance Degradation","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.0;8.5;8.0;7.0;6.1;6.0.2","Edition":"Base;Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
19 January 2022
UID
swg21448581