Ari,
> A possible scenario is as following: 2 web servers A,B and a load
> balancer (local director ) C that balances requests made from
> browsers to the appropriate web server according to the load on each
> box.
> Say each web server capacity is 50 users and there are 50 users
> logged to server A. Due to some time-out (browser/transport layer) a
> user stops interacting with A and instead a subsequent user is
> assigned to A . When the original user that timed-out due to the
> transport layer tries to proceed his session (with possibly valid
> HttpSession) he is assigned to server B since A is in full capacity
> (50).
> [...]
>
> The question: is there a way to force a load balancer to maintain a
> browser's session that started with a web server (as long as it
> didn't time-out due to the server session time-out ) to persist with
> that web server ?
I'm told that local director has some option to make the user's
HTTP sessions "sticky", based on IP numbers, so over a short span of
time (10-30 minutes?) they'll keep going to the same server. I'm not
sure how exactly this is implemented (and neither was the guy who told
me :-) so it doesn't exactly fill me with quiet confidence. I once
considered using client IP number address for doing sessions (way back
in the dawn of web time, before cookie support was widely adopted) but
there are far too many odd cases (proxys servers, firewalls, etc)
where they aren't reliable.
I'd love it if somebody who knows local director well could
explain how it does its domain name and port mapping. I had thought,
based on very sketchy descriptions given to me, that local director
was basically a router that does round-robining, and hence the domain
and port mapping worked essentially like a firewall. But recently
I've been told that's not it (but I haven't been told what it *is*).
The "white papers" at Cisco's web site don't really seem to go into
the details of how it's implemented.
Steven J. Owens
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
