SSL session timeout even though stickiness=session ID

former_member1090788 — Thu, 29 Apr 2004 22:29:41 GMT

EP6 SP1 Patch 1 HF9

We're having a problem trying to use SSL session ID as the stickiness method on the load balancer. While we have "everything" set to at least 1 hour for inactivity timeout on the load balancer (Cisco 11050), web server and J2EE (see below), we experience the following symptom:

1. User logs in successfully to portal using SSL, using IE 6 SP1, with latest patches. They're sent to website #1. Load balancer creates entry in sticky table for that session ID.

2. User does nothing for a period of time less than 1 hour. Seems like less than 5 minutes, we're ok, >5 minutes to 1 hour is the problem, but not consistent.

3. User clicks again in the portal on TLN (native portal page, not even ITS iView or homegrown iView), and after a very long pause (say 30-60 seconds), we finally get either a "action canceled" or "page cannot be displayed" error.

4. Next click allows user to continue to destination without logging in, like nothing was ever wrong.

My feeling is that:

- it's either browser-related, IIS web server related, or J2EE server related. If the inactivity was longer than an hour, we'd be prompted with the login page again, and we'd be load balanced again, potentially to a different website and receive a new session ID.

- since I'm NOT being prompted to login, my session must still be good according to our Web Access Management plugin and the load balancer. J2EE accepts the subsequent click (and we're sent back to same website and thus same J2EE server), so the load balancer sticky entry is still valid.

We have set:

Load balancer session inactivity timeout = 1 hour

Load balancer max session lifetime = 2 hours

WAM plugin inactivity timeout = 1 hour

WAM max session lifetime = 2 hours

Web server SChannel ServerCacheTime (SSL session expiration) = 2 hours (this didn't seem to help)

J2EE http service keepalivetimeout = 1 hour

SAP cookie lifetime = 8 hours

Any we're missing?

In the meantime, is there anything you can suggest to identify the problem, or if other customers are successfully using SSL session ID as the stickiness method? We'd prefer to use session ID instead of source IP if at all possible. The HA Guide for EP6 only mentions source IP (not good for customers with proxies, ISP's or mega-proxies) and cookie based stickiness (doesn't work with SSL).

Any ideas?

Re: SSL session timeout even though stickiness=session ID

former_member1090788 — Wed, 05 May 2004 19:12:11 GMT

Does anyone know how to control the behavior of the Distributed Session Manager in the Portal (SP1)? Specifically, whether it can associate a session with multiple connections, say an old one then be able to use a new one?

Re: SSL session timeout even though stickiness=session ID

Former Member — Sun, 26 Mar 2006 01:16:22 GMT

Jim - I'm new to Cisco and am focusing on our solutions for SAP customers, specifically for the load balancing products. Are there any issues you have where I might be able to help out.

If so, please contact me at dosilver@cisco.com or +1 650-346-8945..... Doug

Question Re: SSL session timeout even though stickiness=session ID in Technology Q&A

SSL session timeout even though stickiness=session ID

Re: SSL session timeout even though stickiness=session ID

Re: SSL session timeout even though stickiness=session ID