Troubleshooting
Problem
When Persistent sessions or PMI is enabled and a Java.io.NotSerializableException occur in logs, you will see the following example error message.
[]
[10/4/02 10:11:10:172 EDT] 28b7c18b SessionContex X WTRN0047E:
java.io.NotSerializableException: COM.ibm.db2.jdbc.app.DB2Connection
[
]
Cause
The class name at the end of the exception is the object that does not implement the java.io.Serializable or java.io.Externalizable interface. In most instances, this object is the attribute that was put into the session object; however, sometimes this object is referenced by an attribute of the session object.
To determine which attribute of the session object references this non-serializable object, access the SessionInspectServlet.
Resolving The Problem
- Implement the Java.io.Serializable or Java.io.Externalizable interface
With persistent sessions enabled, any object that is put into the HTTPSession must implement the serializable interface in order for session manager to store the session data outside of JVM.
When PMI is enabled, there is a counter for session data size. In order to evaluate this counter, the session data must be serialized into a byte array stream. Any object that is put into the HTTPSession must implement the serializable interface in order for session manager to convert the session data objects into byte array stream.
For example:
public class MyObject implements Serializable {
}//end of class MyObject
Check that all objects placed in the HTTPSession implement the java.io.Serializable or java.io.Externalizable interface.
- Acess the SessionInspectServlet
If the class name printed in the exception is not an object that is explicitly placed into the HTTPSession, use the SessionInspectServlet to determine the attribute in the HTTPSession that references a non-serializable object.
SessionInspectServlet helps application writers to determine if application is written to support session persistence. SessionInspectServlet helps to:
- Determine attributes present in the session
- Determine serializable and non-serializable attributes in the session
- Determine the size of each serializable attribute in session
- Determine if serializable attribute is implemented properly (if serializable attribute and all its internals are serializable)
Servlet serializes and deserializes attributes into memory to simulate session persistence; therefore, application writers need not turn on session persistence to run this servlet. However, you can run it with persistent sessions enabled.
How to Access the SessionInspectServlet:
- com.ibm.ws.webcontainer.httpsession.SessionInspectServlet is shipped with WebSphere Application Server. It is already in the classpath and does not need to be added to the application.
Define a servlet/uri entry for class SessionInspectServlet. If ServeServletsByClassnameEnabled is set to true (check the ibm-web-ext.xmi file in the WEB-INF directory of your webModule) in your webModule, servlet/uri definition is not needed.
- Restart your Web module.
- Open a browser and access your Web module from the browser, then navigate the application in the browser to populate the session.
- Press Crtl+N to open a new browser, then access the SessionInspectServlet in the new browser by calling the URI that you defined in step 2. If you are using ServeServletsbyClassname, the URI will be "webapp_context_root\servlet\com.ibm.ws.webcontainer.httpsession.SessionInspectServlet". This displays the session details at that moment. You can access the servlet as you navigate your application to determine the session contents as you go along. Note: The servlet does not support attributes in the session that are outside the WebSphere Application Server scope. That is, session contents need to be accessed by the server class loader scope.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21066791