Steven,
I've worked with local director from a developer's perspective, and you're
right about the sticky routing, but my experience tells me it's not
foolproof. (It had a tendency to overload the first machine). Also, if the
original server is timing out, the user could still end up at another
server. I don' t think there's a completely foolproof way to ensure that
the user will always end up on a particular server _without_ making the
user vulnerable to the sensitivities of that server. If server A goes down,
the user should always be routed to another server. And remember that a
dead server and a slow server both look the same to local director (i.e.,
not responding fast enough). I've found that the best thing to do is have
the client maintain information (via cookies or perhaps URL rewriting) and
work with it on the server in a server-independent manner (i.e. server A
doesn't care works the same if the user comes from server B, C, or D).
As far as the way local director works, I don't know about it at the
network level, but I do know that it:
a. can do ordinary round-robin dispatching to a pool of servers
b. can do sticky routing
c. may have other methods of routing
d. has port number mappings (i.e. www.myhost.com:8080 gets sent to
appserver.myhost.com:2010, behind the firewall)
Anyway, I hope this helps...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
Kito D. Mann
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Wednesday December 8, 1999 12:06 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Kito Mann/PSG/Prudential)
Subject: Re: Load balancing disables persistence with HttpSession ?
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
___________________________________________________________________________
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
