Random java.lang.StackOverflowError on weblogic cluster
Having issue on WLS 10.3.4 across a cluster environment, having random java.lang.StackOverflowError, Env. is like below
OS : RH Linux 5
Intel 32-64 bit
WLS 10.3.4
Jrockit : jrockit-jdk1.6.0_20-R28.1.0-4.0.1
####<Jan 10, 2012 12:03:51 AM EST> <Error> <Kernel> <techpaste.com> <server2> <ACTIVE ExecuteThread: '9' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <99d28a379c110560:-29d52cf2:134c422fe59:-7ffd-00000000000150e3> <1326171831101> <BEA-000802> <ExecuteRequest failed java.lang.StackOverflowError. java.lang.StackOverflowError at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) ............ java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:416) at com.sun.org.apache.xerces.internal.dom.ParentNode.writeObject(ParentNode.java:1002) at sun.reflect.GeneratedMethodAccessor391.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) ............ ------------- at java.util.HashMap.writeObject(HashMap.java:1195) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at weblogic.servlet.internal.session.ReplicatedSessionChange.writeExternal(ReplicatedSessionChange.java:153) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at weblogic.rjvm.MsgAbbrevOutputStream.writeObject(MsgAbbrevOutputStream.java:618) at weblogic.rjvm.MsgAbbrevOutputStream.writeObjectWL(MsgAbbrevOutputStream.java:609) at weblogic.rmi.internal.ObjectIO.writeObject(ObjectIO.java:38) at weblogic.rjvm.BasicOutboundRequest.marshalArgs(BasicOutboundRequest.java:88) at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:221) at weblogic.cluster.replication.ReplicationManager_1034_WLStub.update(Unknown Source) at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) un.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at weblogic.cluster.replication.SecureReplicationInvocationHandler$ReplicationServicesInvocationAction.run(SecureReplicationInvocationHandler.java:194) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.cluster.replication.SecureReplicationInvocationHandler.invoke(SecureReplicationInvocationHandler.java:164) at $Proxy168.update(Unknown Source) at weblogic.cluster.replication.ReplicationManager.sendUpdateRequestToSecondary(ReplicationManager.java:742) at weblogic.cluster.replication.ReplicationManager.updateSecondary(ReplicationManager.java:666) at weblogic.servlet.internal.session.ReplicatedSessionData.syncSession(ReplicatedSessionData.java:639) at weblogic.servlet.internal.session.ReplicatedSessionContext.sync(ReplicatedSessionContext.java:85) at weblogic.servlet.internal.ServletRequestImpl$SessionHelper.syncSession(ServletRequestImpl.java:2860) at weblogic.servlet.internal.ServletRequestImpl$SessionHelper.syncSession(ServletRequestImpl.java:2835) at weblogic.servlet.internal.ServletResponseImpl$1.run(ServletResponseImpl.java:1485) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1479) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1462) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207) at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)
it’s usually seen when you put a corrupt hashmap into the session such that the internal next pointers of two entries in the hashmap/hashtable point back to each other and thus cause an infinite loop while writing the data.
You need to look into the deployed application to see whether store in the session have UNsynchronized access and find out if any of the hashmaps they store in the session have synchronized access to them (that can usually cause a hashmap to get corrupted when two threads are resizing it at the same time).
You may ask for a heap dump when this happens so that you can look into the session to see if you can find any such hashmap. Otherwise, go over all app code.
In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.