tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James House <james.ho...@partnet.com>
Subject RE: Distributed Session Server
Date Wed, 28 Jun 2000 22:59:36 GMT

We have need of a distributed session server because we'd like to use
load-balancing hardware/software to distribute requests over a cluster
of servers.

The problem is, you don't know which request is going to go to which
server, so you don't know which server needs the session data, until
the request gets there - at which point it would obviously request the
session data from the would-be session server.

(Some load balancers allow sessions to "stick" to a given server -
or in other words, once it sends a request from a given IP address
to a given server, it will always send request for that IP address to
the same server.  This partly solves the problem, but when that
server goes down, the load balancer switches the requests to a
different servers - which then obviously needs the session data).

The biggest hurdle in all of this is moving that session data in a
reasonable amount of time, and overcoming concurrency issues
(the same user might open two browser windows, and make to
request at the same moment - which the load balancer may send
to two distinct web servers).

I'd have built this thing by now if I could figure out how to move
200k to 1200k worth of data in a "reasonable amount of time"
- as those are our particular data needs. (we stick that much
on a session)

James

>I've been thinking about the distributed session problem a bit.  I
>think it would be possible to have a compromise between sticky and
>distributed sessions, distinguished by graceful and abrupt termination
>of a JVM.
>
>Specifically, I think it would be possible to build a session
>manager that fails sessions over to alternate JVMs during a
>graceful shutdown of a container.  An abrupt shutdown of the
>container, on the other hand, would cause session loss of some
>subset of the sessions.
>
>The key ideas in no particular order:
>
>1.  Write-through session state to session storage (data base,
>     or a session server, or something else) only when
>
>     1.a.  Graceful shutdown is occurring, or
>
>     1.b.  The session has been `idle' for some duration (10min?)
>     Note that 1.b. has some significant flexibility (the 10 min
>     is invisible to the user) to balance memory consumption of
>     the JVM and the execution overhead of the JVM.
>
>2.  When you need to restart tomcat, do a rotating restart,
>     rotating across your machines:
>
>     2.a.  Tell Apache not to send new requests (not associated
>     with a session) to the new machine.
>
>     2.b.  Start up a new JVM to replace the old.  Point all
>     requests for old sessions to this new JVM.
>
>     2.c.  Initiate a graceful shutdown in the old JVM, so all
>     recently active sessions are serialized to the session store.
>     This will be somewhat slow.
>
>     2.d.  As requests from old sessions come in to the new JVM,
>     session state is restored from the session store, or the
>     request is blocked if the old JVM has not yet posted that
>     session.  The trick here is to somehow make sure the blocked
>     request doesn't take too long; don't know how to solve this
>     one yet.
>
>     2.e.  After all sessions are serialized, the old JVM can
>     simply exit; it will not get any more requests anyway due to
>     2.b.
>
>The `rotating' part is not necessary, and will only work if your
>persistent store is set up to deal with both the old and new
>configs.  If your persistent store is *not* set up in this manner,
>and only is backwards compatible, then you need to start up all new
>JVMs in parallel, and then in one fell swoop point all requests to
>the new set of JVMs, and let the sessions migrate at that point.
>
>The balance that should be struck is between the number of active
>sessions, how long before you serialize/store an active session, and
>how long it takes to do the graceful shutdown/movement of all the
>sessions.
>
>If your code has memory leaks or you notice JVMs getting dangerously
>big, you can fail over a JVM at any time . . . and also, this allows
>sessions to time out mostly in the session server rather than in
>the JVM memory (so the first 10 min of the session timeout is in
>the JVM, but the remaining 110 min or whatnot is strictly in the
>session server . . .)
>
>Is this all stupid?  Or obvious?  Any thoughts?
>
>-tom
>
>-----Original Message-----
>From: Jon Stevens [mailto:jon@latchkey.com]
>Sent: Wednesday, June 28, 2000 2:50 PM
>To: tomcat-dev@jakarta.apache.org
>Subject: Re: Distributed Session Server
>
>
>on 6/28/2000 2:04 PM, "Peter Wong" <ypwong1025@hotmail.com> wrote:
>
> > I totally agree that having the ability to separate out the dedicated
> > session server would make the product more robust and marketable too. If
> > this could be done efficiently. that is a great idea and great solution to
> > many business. :) for me too
>
>SourceXchange.com/Collab.Net is willing to fund this project.
>
>Someone want to write up an RFP?
>
>-jon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message