Background:

We have three web servers load balanced behind a couple of Cisco 11501 load balancers. We use sticky sessions to assure that once a user logs on, they stay with the same web server for their entire session. (We cache user permissions, so they need to return to the same server for each request.) We had been running JRun application server and using the JRun cookie "jsessionid" to tell the load balancer where an individual request originates, and therefore which server to send the request. This has worked fine for the last 5 years.

Our problem:

We're switching application servers, from JRun to Tomcat. Our hosting company is unable to get sticky sessions working with Tomcat.

Tomcat uses a slightly different cookie ("JSESSIONID"vs. "jsessionid" and Tomcat's session id string is 32 characters vs. 19 for JRun, but a cookie is a cookie, so if it could balance on one, it can balance on another, right?

We've used sticky sessions before with Barracuda and F5 load balancers, and we set up Pound and Tomcat works it just fine, so we cannot understand why this is a problem with the Cisco LB's.

Anyone else have problems with Tomcat sticky sessions behind Cisco load balancers?

link|improve this question
Are you storing the cookie in the http cookie header or the URL? In the header there can be issues if the header is HUGE (it might not work by default if the header is > 5 packets in size). It won't work if the header is greater than 20 packets in size. Great bits here: cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/… – user6373 Nov 12 '09 at 17:52
The cookie is in the http headers. The hosting company gave up on getting this to work and just had the LB set it's own cookie. Kind of a kludge, but it does work. – Def Mango Raygun Nov 20 '09 at 16:14
feedback

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

Your Answer

 
or
required, but never shown

Browse other questions tagged or ask your own question.