tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Nock" <>
Subject RE: Load Balancing for WEB-Application with sessions
Date Mon, 23 Jul 2001 17:19:36 GMT
jk_mount/loadbalancing works well for this kind of thing.  We use it
loadbalancing across multiple servers, with multiple JVMs on each server.

The only issue we had was in the way our (Foundry) loadbalancer handled

We needed session state preserved by cookie or sessionid, and it proved
'difficult' to make the loadbalancer work in this way with the default
tomcat session state stuff, ie.
cookie name = JSESSIONID

Problem is the loadbalancer pattern matching used to preserve sessions by
URL couldn't do matching for cases like:;jsessionid=*.worker
where the pattern to be matched is the ;jsessionid=*.worker

Cookie matching wasn't much better either, so we resorted to adding an extra
cookie in our application that was purely for use by the loadbalancer to
send the request to the right machine.

What we resorted to was rebuilding tomcat changing the name of 'jsessionid'
to something that identified the node so the loadbalancer knew where to send

Works fine, if a bit messy due to hardware limitations.


-----Original Message-----
From: []
Sent: Monday, July 23, 2001 2:16 AM
Subject: Load Balancing for WEB-Application with sessions


For improving the performace, we are going to serve requests with many
computers. Here, a problem with redirection arises. As a rule, the requests
are randomly redirected to the existent servers, and it functions well for
undependent pages and servlets. We have to ensure that a hole session is
processed on (redirected to) the same server. Are there possibilities to do
it in Tomcat, or we have to write a redirector-servlet ourselves, to
control the redirections according to the session.

Mit freundlichen Grüßen

Christian Schildt
Diplom-Betriebswirt (FH)


Phone: 089/89013023
Gutenbergstr. 5
D-82178 Puchheim bei München
Phone: +089/8901300
Fax:   +089/89013089

View raw message