PK58572: OUTOFMEMORY OCCURS WHEN WE HAVE FAILURE IN WORKSPACE DISCARD ANDWHEN A WORKSPACE IS SHARED BY MULTIPLE THREADS

APAR status
Closed as fixed if next.

Error description
In WebSphere Application Server 5.1,OutOfMemory occurs when we
have failure in workspace discard when a workpsace is shared by
multiple threads.


We see the following in the native_stderr.log file:

<AF[2135]: Allocation Failure. need 8208 bytes, 1 ms since last
AF>
<AF[2135]: managing allocation failure, action=2
(7408/536869376)>
  <GC(2579): mark stack overflow[2249]>
  <GC(2579): GC cycle started Tue Jul 17 03:43:27 2007
  <GC(2579): freed 18600 bytes, 0% free (26008/536869376), in
   2947 ms>
  <GC(2579): mark: 881 ms, sweep: 30 ms, compact: 2036 ms>
  <GC(2579): refs: soft 0 (age >= 32), weak 0, final 0, phantom
   0>
  <GC(2579): moved 2590 objects, 156280 bytes, reason=1, used
   3280 more bytes>
<AF[2135]: managing allocation failure, action=3
(26008/536869376)>
<AF[2135]: managing allocation failure, action=4
(26008/536869376)>
<AF[2135]: clearing all remaining soft refs>
  <GC(2580): mark stack overflow[2250]>
  <GC(2580): GC cycle started Tue Jul 17 03:43:30 2007
  <GC(2580): freed 144 bytes, 0% free (26152/536869376), in 3019
   ms>
  <GC(2580): mark: 979 ms, sweep: 31 ms, compact: 2009 ms>
  <GC(2580): refs: soft 2 (age >= 32), weak 0, final 0, phantom
   0>
  <GC(2580): moved 419 objects, 23672 bytes, reason=1>
<AF[2135]: managing allocation failure, action=6
(26152/536869376)>
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to
/opt/WebSphere01/DeploymentManager/heapdump.20070717.034330.2541
1.phd
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[2135]: Insufficient space in Javaheap to satisfy allocation
request>
<AF[2135]: completed in 20225 ms>

The corresponding heap dump shows the heap is exhausted:

463,299,264 [24] 2
com/ibm/ws/sm/workspace/impl/WorkSpaceManagerImpl
0x178faec0
 463,299,240 [48] 1 java/util/HashMap 0x178dc1e0
  463,299,192 [528] 56 array of java/util/HashMap$Entry
0x16a72b60
   21,216,864 [32] 3 java/util/HashMap$Entry 0x15c24308
   18,829,816 [32] 3 java/util/HashMap$Entry 0x1293a310
   18,074,872 [32] 3 java/util/HashMap$Entry 0x1c22f480
   17,166,616 [32] 3 java/util/HashMap$Entry 0x245fb4b8
   16,954,912 [32] 3 java/util/HashMap$Entry 0x2b6cbf60
   16,429,264 [32] 3 java/util/HashMap$Entry 0x16857908

The problem appears to be caused by the class:

com.tivoli.jmx.modelmbean.MMBInvoker.invoke(MMBInvoker.java:46)

which is creating, but not deleting, several hundred workspaces.
Local fix
To avoid the issue, increase the com.ibm.SOAP.requestTimeout
value.
Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
****************************************************************
* PROBLEM DESCRIPTION: In WebSphere Application Server         *
*                      V5.1, OutOfMemory occurs when we        *
*                      have failure in workspace discard       *
*                      when a workpsace is shared by           *
*                      multiple threads.                       *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
In WebSphere Application Server 5.1,OutOfMemory occurs when we
have failure in workspace discard when a workpsace is shared by
multiple threads.


We see the following in the native_stderr.log file:

<AF[2135]: Allocation Failure. need 8208 bytes, 1 ms since last
AF>
<AF[2135]: managing allocation failure, action=2
(7408/536869376)>
<GC(2579): mark stack overflow[2249]>
<GC(2579): GC cycle started Tue Jul 17 03:43:27 2007
<GC(2579): freed 18600 bytes, 0% free (26008/536869376), in
2947 ms>
<GC(2579): mark: 881 ms, sweep: 30 ms, compact: 2036 ms>
<GC(2579): refs: soft 0 (age >= 32), weak 0, final 0, phantom
0>
<GC(2579): moved 2590 objects, 156280 bytes, reason=1, used
3280 more bytes>
<AF[2135]: managing allocation failure, action=3
(26008/536869376)>
<AF[2135]: managing allocation failure, action=4
(26008/536869376)>
<AF[2135]: clearing all remaining soft refs>
<GC(2580): mark stack overflow[2250]>
<GC(2580): GC cycle started Tue Jul 17 03:43:30 2007
<GC(2580): freed 144 bytes, 0% free (26152/536869376), in 3019
ms>
<GC(2580): mark: 979 ms, sweep: 31 ms, compact: 2009 ms>
<GC(2580): refs: soft 2 (age >= 32), weak 0, final 0, phantom
0>
<GC(2580): moved 419 objects, 23672 bytes, reason=1>
<AF[2135]: managing allocation failure, action=6
(26152/536869376)>
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to
/opt/WebSphere01/DeploymentManager/heapdump.20070717.034330.2541



1.phd
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[2135]: Insufficient space in Javaheap to satisfy allocation
request>
<AF[2135]: completed in 20225 ms>

The corresponding heap dump shows the heap is exhausted:

463,299,264 [24] 2
com/ibm/ws/sm/workspace/impl/WorkSpaceManagerImpl
0x178faec0
463,299,240 [48] 1 java/util/HashMap 0x178dc1e0
463,299,192 [528] 56 array of java/util/HashMap$Entry
0x16a72b60
21,216,864 [32] 3 java/util/HashMap$Entry 0x15c24308
18,829,816 [32] 3 java/util/HashMap$Entry 0x1293a310
18,074,872 [32] 3 java/util/HashMap$Entry 0x1c22f480
17,166,616 [32] 3 java/util/HashMap$Entry 0x245fb4b8
16,954,912 [32] 3 java/util/HashMap$Entry 0x2b6cbf60
16,429,264 [32] 3 java/util/HashMap$Entry 0x16857908

The problem appears to be caused by the class:

com.tivoli.jmx.modelmbean.MMBInvoker.invoke(MMBInvoker.java:46)

which is creating, but not deleting, several hundred
workspaces.

It would be very difficult to have this changes as a part of
APAR. After few discussions with architecture, we came to the
conclusion  that this defect involves more than 2 websphere
components. It would involve large changes and so it
involves extra testing process.
Problem conclusion Temporary fix Comments
It would be very difficult to have this changes as a part of
APAR. After few discussions with architecture, we came to the
conclusion  that this defect involves more than 2 websphere
components. It would involve large changes and so it
involves extra testing process.
APAR information
APAR number PK58572
Reported component name WAS NETWRK DEPL
Reported component ID 5630A3601
Reported release 10I
Status CLOSED FIN
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2007-12-21
Closed date 2008-02-01
Last modified date 2008-02-01

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Publications Referenced

Fix information

Applicable component levels
R003 PSY    UP
R00A PSY    UP
R00H PSY    UP
R00I PSY    UP
R00P PSY    UP
R00S PSY    UP
R00W PSY    UP
R103 PSY    UP
R10A PSY    UP
R10H PSY    UP
R10I PSY    UP
R10P PSY    UP
R10S PSY    UP
R10W PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 10I
Software edition:
Reference #: PK58572
IBM Group: Software Group
Modified date: Feb 1, 2008