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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros Publications Referenced
|
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
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.