HTTP session problems

 

+

Search Tips   |   Advanced Search

 

To view and update the session manager settings...

appserver | Additional properties | Web Container | Session manager

Issues:

  1. HTTP Sessions are not getting created, or are lost between requests.
  2. HTTP Sessions are not persistent. Session data lost when appserver restarts, or not shared across cluster
  3. Session is shared across multiple browsers on same client machine.
  4. Session is not getting invalidated immediately after specified session timeout interval.
  5. Unwanted sessions are being created by JavaServer Pages.
  6. Session data intended for one client is seen by another client.
  7. A ClassCastException error occurs during failover of a session that contains an EJB .
  8. Users are not logged out after HTTP session timer expires

If your problem is not described here, or none of these steps fixes the problem:

  1. Review HTTP session manager troubleshooting tips
  2. Review Task overview: Managing HTTP sessions
  3. Look at the available online support
  4. Contact IBM support.

 

HTTP sessions are not getting created, or are lost between requests

By default, the session manager uses cookies to store the session ID on the client between requests. Unless you intend to avoid cookie-based session tracking, ensure that cookies are flowing between WAS and the browser:

  • Make sure the Enable cookies check box is checked under the Session tracking Mechanism property.

  • Make sure cookies are enabled on the browser you are testing from or from which your users are accessing the application.

  • Check the Cookie domain specified on the SessionManager

    • For example, if the cookie domain is set as ".myCom.com", resources should be accessed using that domain name.

      For example...

      http://www.myCom.com/myapp/servlet/sessionservlet

    • If the domain property is set, make sure it begins with a dot (.). Certain versions of Netscape do not accept cookies if domain name doesn't start with a dot. Internet Explorer honors the domain with or without a dot. For example, if the domain name is set to mycom.com, change it to .mycom.com so that both Netscape and Internet Explorer honor the cookie.

      When the servers are on different hosts, ensure that session cookies flow to all the servers by configuring a front-end router such as a Web server with the plug-in or setting the Cookie domain.

  • Check the Cookie path specified on the SessionManager. Check whether the problem URL is hierarchically below the Cookie path specified. If not correct the Cookie path.

  • If the Cookie maximum age property is set, ensure that the client (browser) machine's date and time is the same as the server's, including the time zone. If the client and the server time difference is over the "Cookie maximum age" then every access would be a new session, since the cookie will "expire" after the access.

  • If you have multiple Web modules within an enterprise application that track sessions:

    • To have different session settings among Web modules in an enterprise application, ensure that each Web module specifies a different cookie name or path, or

    • If Web modules within an enterprise application use a common cookie name and path, ensure that the HTTP session settings, such as Cookie maximum age, are the same for all Web modules. Otherwise cookie behavior will be unpredictable, and will depend upon which application creates the session. Note that this does not affect session data, which is maintained separately by Web module.

  • Check the cookie flow between browser and server:

    1. On the browser, enable "cookie prompt". Hit the servlet and make sure cookie is being prompted.

    2. On the server, enable SessionManager trace. Enable tracing for the HTTP session manager component, by using the trace specification...

      com.ibm.ws.webcontainer.httpsession.*=all=enabled"

      After trace is enabled, exercise your session-using servlet or jsp, then follow the instructions for dumping and browsing the trace output .

    3. Access the session servlet from the browser.

    4. The browser will prompt for the cookie; note the jsessionid.

    5. Reload the servlet, note down the cookie if a new cookie is sent.

    6. Check the session trace and look for the session id and trace the request by the thread. Verify that the session is stable across Web requests:

      • Look for getIHttpsession(...) which is start of session request.
      • Look for releaseSesson(..) which is end of servlet request.

  • If you are using URL rewriting instead of cookies:

  • If you are using SSL as your session tracking mechanism:

  • If you are in a clustered (multiple node) environment, ensure that you have session persistence enabled.

 

HTTP Sessions are not persistent

If your HTTP sessions are not persistent, that is session data is lost when the appserver restarts or is not shared across the cluster:

  • Check the data source.

  • Check the session manager's persistence settings properties:

    • If you intend to take advantage of session persistence, verify that Persistence is set to Database.

    • Persistence could also be set to Memory-to-Memory Replication.

    • If you are using Database-based persistence:

      • Check the JNDI name of the data source specified correctly on SessionManager.

      • Specify correct userid and password for accessing the database.

        Note that these settings have to be checked against the properties of an existing data source in the console. The session manager does not automatically create a session database for you.

      • The data source should be non-JTA, for example, non XA enabled.

      • Check the JVM logs for appropriate database error messages.

      • With DB2, for row sizes other than 4k make sure specified row size matches the DB2 page size. Make sure tablespace name is specified correctly.

    • If you are using memory-based persistence (available only in a network deployment environment):

 

Session is shared across multiple browsers on same client machine

This behavior is browser-dependent. It varies between browser vendors, and also may change according to whether a browser is launched as a new process or as a subprocess of an existing browser session (for example by hitting Ctl-N on Windows).

The Cookie maximum age property of the session manager also affects this behavior, if cookies are used as the session-tracking mechanism. If the maximum age is set to some positive value, all browser instances share the cookies, which are persisted to file on the client for the specified maximum age time.

 

Session is not getting invalidated immediately after specified session timeout interval

The SessionManager invalidation process thread runs every x seconds to invalidate any invalid sessions, where x is determined based on the session timeout interval specified in the session manager properties. For the default value of 30 minutes , x is around 300 seconds. In this case, it could take up to 5 minutes (300 seconds) beyond the timeout threshold of 30 minutes for a particular session to become invalidated.

 

Unwanted sessions are being created by JavaServer Pages

As required by the JavaServer Pages specification, JSP pages by default perform a request.getSession(true), so that a session is created if none exists for the client. To prevent JSP pages from creating a new session, set the session scope to false in the .jsp file using the page directive as follows: 

<% @page session="false" %>

 

Session data intended for one client is seen by another client

In rare situations, usually due to application errors, session data intended for one client might be seen by another client. This situation is referred to as session data crossover. When the DebugSessionCrossover custom property is set to true, code is enabled to detect and log instances of session data crossover. Checks are performed to verify that only the session associated with the request is accessed or referenced. Messages are logged if any discrepancies are detected. These messages provide a starting point for debugging this problem. This additional checking is only performed when running on the WebSphere-managed dispatch thread, not on any user-created threads.

For additional information on how to set this property, see article, Web container custom properties.

 

A ClassCastException error occurs during failover of a session that contains an Enterprise JavaBeans (EJB) reference

If you run WebSphere® Application Server for z/OS® V6.0.1 and configure a session manager to replicate EJB references, a session failover might trigger display of the following exception in the server region job log: 

java.lang.ClassCastException: cannot cast class
       org.omg.stub.java.rmi._Remote_Stub to interface javax.ejb.EJBObject
The log also displays a null pointer exception. The problem results from the session outbound request, where WAS for z/OS issued a CORBA::COMM_FAILURE exception with a C9C21355 minor code. This behavior occurs because your appserver contains all of the following configurations:

  1. SAF is both the local operating system, as well as the user registry

  2. Attribute propagation is enabled

  3. An unauthenticated user initiated the session outbound request

To correct this problem apply the APAR PK06777 fix to WebSphere Application Server for z/OS V6.0.1. You can retain the previously mentioned server configurations.

 

Users are not logged out after the HTTP session timer expires

If users of WAS log onto an application and sit idle longer than the specified HTTP session timeout value, the user information is not invalidated and user credentials stay active until LTPA token timeout occurs. To log out users from the application after the HTTP session has expired apply PK25740 and then complete the following steps...

  1. In the console, click...

    Security | Secure administration, applications, and infrastructure | Custom properties | New

  2. In the Name field, enter...

    com.ibm.ws.security.web.logoutOnHTTPSessionExpire

  3. In the Values field, enter true.

  4. Click Apply and Save to save the changes to the configuration.

  5. Resynchronize and restart the server.

 

See Also

IBM Support has documents and tools that can save you time gathering information needed to resolve problems as described in Troubleshooting help from IBM.



 

Related concepts


Sessions

 

Related tasks

Task overview: Managing HTTP sessions

 

Related Reference

Best practices for using HTTP Sessions
HTTP session manager troubleshooting tips