Intermittent session-related or HTTP errors are unexpected errors that cannot be consistently reproduced, for example, HTTP 403 forbidden errors and premature or unexpected session timeouts.

Typical causes

Intermittent session-related or HTTP errors are typically caused by inconsistent web-tier configuration across cluster nodes, for example, inconsistent configuration of session cookies. Intermittent session-related or HTTP errors are also caused by errors during session passivation or reactivation.

Information to collect

Collect the following information to assist with troubleshooting:

• Screenshots, user IDs, and timings of the problem
• Application server logs
• If your environment uses WebSphere Application Server (WAS), collect the WAS plugin configuration file, specifically plugin-cfg.conf, from each HTTP server
• Fiddler or browser HTTP traces
• User activity before the error occurred with steps to reproduce the error

Troubleshooting

When troubleshooting the issue, validate that the following session-timeout related values are correct:

• In the .environment file in NexJ Studio, validate the Session Timeout value in the Clustering/Session subtab of the Overview tab.
• In the System page in NexJ System Admin Console, validate the Persistent Session Timeout (minutes) value.

Examine application server logs and look for errors related to session passivation or reactivation. For example:

[10/07/17 07:52:08:748 BST] 000000a6 SessionManager Cannot save the state of session htfyBx_ZOZdO-nqykrhIt9G…

If possible, reproduce the issue in a single-node configuration.

If your environment uses WebSphere Application Server (WAS), ensure that the NEXJSESSIONID session cookie name is consistent across these locations:

• NexJ environment file (sessionCookie=“NEXJSESSIONID”)
• WAS configuration of the deployed application under Session Management
• WAS plugin, in the plugin-cfg.conf file, on each HTTP server

Capture Fiddler, or Chrome and Internet Explorer HTTP traces of the problem. Examine response headers for abnormalities, for example, examine Set-Cookie HTTP response headers.

Additional considerations

Consider the following potential session cookie name conflicts:

• By default, the J2EE session cookie name is JSESSIONID and may be used by third-party software and hardware appliances.
• NexJ recommends setting the NexJ CRM session cookie name to NEXJSESSIONID to avoid potential conflicts with other components in the network path between the browser and the NexJ CRMapplication cluster.

All sessions must be passivated before they can be load balanced between application nodes. A passivated session has been serialized and saved to the NJSession database.

WebSphere and the NexJ application rely on the session cookie value to direct HTTP requests to the correct node, specifically the node affinity portion of the value. For example, NEXJSESSIONID=0000idhshMx0AuiafQRP63OyjFQ:1a2as615b where 0000idhshMx0AuiafQRP63OyjFQ represents the session ID and 1a2as615b represents the node ID.