Use troubleshooting information for problems when creating
or using Hypertext Transfer Protocol (HTTP) sessions.
To view and update the session manager settings discussed here,
use the administrative console. Select the application server that
hosts the problem application, then under Additional properties, select Web Container, then Session manager.
What kind of problem are you having?
![[IBM i]](../images/iseries.gif)
If your problem is not described here,
or none of these steps fixes the problem:
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 WebSphere Application Server 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 (to view
the or update the cookie settings, in the , click Modify).
- 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 expires after the access.
- If you have multiple web modules within an enterprise application
that track sessions:
- If you want 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 is unpredictable, and depends upon which application creates
the session. Note that this does not affect session data, which is
maintained separately by the web module.
- Check the cookie flow between browser and server:
- On the browser, enable "cookie prompt". Hit the servlet and
make sure cookie is being prompted.
On the server, enable SessionManager trace.
Enable tracing for the HTTP session manager component, by using the
trace specification "com.ibm.ws.session.*=all=enabled". After
trace is enabled, exercise your session-using servlet or JSP, then
follow the instructions for dumping and browsing the trace output
.
- Access the session servlet from the browser.
- The browser prompts for the cookie; note the jsessionid.
- Reload the servlet, note down the cookie if a new cookie is sent.
- 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 releaseSession(..) which is end of servlet request.
- If you are using URL rewriting instead of cookies:
- Ensure there are no static HTML pages on your application's navigation
path.
Ensure that your servlets
and JSP files are implementing URL rewriting correctly. For details
and an example see Session tracking options.
Deprecated feature: Session tracking using the SSL ID is
deprecated in WebSphere Application Server version 7.0.
You can configure session tracking to use cookies or modify the application
to use URL rewriting.
depfeat
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 application server 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:
- 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
(JSP) 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.
Users are not logged out after the HTTP session timer expires
If users of WebSphere Application Server 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.
After you apply
PK25740, complete the following steps to log out users from the application
after the HTTP session has expired.
- In the administrative console, click Security > Global
security.
- Under Custom properties, click New.
- In the Name field, enter com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
- In the Values field, enter true.
- Click Apply and Save to save the changes to your configuration.
- Resynchronize and restart the server.
Unexpected re-authentications: When you set the com.ibm.ws.security.web.logoutOnHTTPSessionExpire
custom property to true, unexpected re-authentications might occur
when you are working with multiple web applications. By default, each
web application has its own unique HTTP session, but the web browser
has one session cookie. To address this issue, you can change the
HTTP session configuration by giving each application a unique session
cookie name or path setting. As a result, each application gets its
own session cookie. Alternatively, you can configure multiple web
applications with the same enterprise application to share the same
HTTP session. For more information, see the Assembling so that session
data can be shared topic.
Exceptions can occur during run time
when updating applications where session persistence is enabled
Users who have session persistence enabled and run application
updates during run time might experience unexpected exceptions after
the application is restarted.
If updates have been made that
change the attributes saved, then all the sessions created by the
associated application might have to be invalidated prior to the application
update if the application can not handle these changes. In this situation,
all session objects must be removed from the back-end as well. See
the HTTP session invalidation information to learn more about how
to remove these sessions properly.
IBM Support
has documents and tools that can save you time gathering information
needed to resolve problems. Before opening a problem report, see the
Support page: