Possible cause: |
The
WebSphere variable transaction_defaultTimeout might have a value
too large. |
Caused by: |
Loop in the application |
JVM runs out of heap
storage, if you are running Java in a servant (region) |
Look for: |
|
- Any error messages from JVM in the job log of the failed servant (region)
|
Actions: |
- Analyze with IPCS to determine whether or not the servant (region) was
looping (application code loop) or waiting (maybe the runtime failed).
- Use the DUMP command to get a console dump of the servant and
its controller.
- If you were utilizing JRAS, look at the JRAS CTRACE entries:
- If the application code was looping, you may see the same entry repeating.
- Ensure that CTRACE writer is on and take a SVC dump at the approximate
time of hang.
- Use the display command to determine the state of the server.
|
- Through the Administrative console, set the WebSphere variable to debug
the JVM; this setting passes information to the JVM and turns on the high-level
messages for you to examine.
- Look for error message or Java stack traces that might indicate an OUT_OF_MEMORY
condition.
- Use application monitoring tools, such as WebSphere Studio Application
Monitor (WSAM) or Jinsight, to look for application memory leaks.
|
For current information available from IBM Support on known problems and
their resolution, see the IBM Support
page.
IBM Support has documents that can save you time gathering information
needed to resolve this problem. Before opening a PMR, see the IBM Support
page.