The following or similar stack will be seen in the current
thread of the javacore
"Servlet.Engine.Transports : X"
com.ibm.rmi.iiop.CDROutputStream.grow
com.ibm.rmi.iiop.CDROutputStream.alignAndReserve
com.ibm.rmi.iiop.CDROutputStream.write_wstring
com.ibm.rmi.iiop.CDROutputStream.writeString
com.ibm.rmi.iiop.CDROutputStream.fast_write_value_internal
com.ibm.rmi.iiop.CDROutputStream.fast_write_value
com.ibm.rmi.iiop.CDROutputStream.fast_write_value
com.ibm.rmi.io.IIOPOutputStream.writeValueType
com.ibm.rmi.io.IIOPOutputStream.writeObjectField
com.ibm.rmi.io.IIOPOutputStream.outputClassFields
com.ibm.rmi.io.IIOPOutputStream.outputObject
com.ibm.rmi.io.IIOPOutputStream.writeSerializable
com.ibm.rmi.io.IIOPOutputStream.simpleWriteObjectInternal
com.ibm.rmi.io.IIOPOutputStream.simpleWriteObjectLoop
com.ibm.rmi.io.IIOPOutputStream.writeObjectDelegate
com.ibm.rmi.io.IIOPOutputStream.writeObjectOverride
The heapdump will show the large object as type:
com/ibm/rmi/iiop/CDROutputStream
This problem occurs when the ORB pieces together chunks returned from a
EJB call. These chunks are assembled on the client side as a temporary
object of CDROutputStream. When CDROutputStream.grow is called, that
temporary object doubles in size to extend the capacity for more chunks to
be assembled.
This object can grow in excess of 8 MB, 16 MB, or 32 MB when large
returns are made by an EJB call.
There are two solutions to this problem.
- Modify the application to limit or reduce the size of an EJB
response.
- Use local instead of remote interfaces and make sure the response
object is of a scalable type, such as a Collection or Vector.
|