tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mika Goeckel" <m...@stepstone.de>
Subject Re: Tomcat 4 Cluster -- plans?
Date Tue, 06 Nov 2001 11:10:00 GMT
Hmm...

another possibiity would be JavaSpaces to store the sessions.

I try to keep in mind how through choosing an appropriate architecture keeps
performance problems out of the way.
An SQL store gives me the impression that the overhead especially in cases
when failover is not needed is paramount.
Sending the complete session to apache as well, plus there are
responsibilities to be sorted out like does apache desice if a session has
timed out? Would need to, because otherwise apache would keep useless data
which would pile up. That leads to two locations where to specify session
time out or the need for apache to retrieve that information out of the
serialized session object, thus tight coupling.

A key (or cookie) is already in use to identify subsequent requests from the
same user, so there would be no need to change anything for that in apache.

Multicast problems could be avoided if a cluster would be explicitely
configured. This would add some means of performance tuning options as well
(a single daisy chain circle would be not so save but replicate the session
faster, a double daisy chain [replication to both adjacent neighbours] or
even a completely connected network would make it more reliable but slower,
because if a direct conection instead of multicast is used, the session
needs to be sent to all receivers one by one).
This leaves another problem open. How would apache know which server has got
a valid copy of the specific session, when one node shuts down? Or could the
cluster solve that by itself, i.e. if a tomcat get's a request with a
sessionkey but can't find the session itself, it could send a request to
it's comrade nodes to ask for it.

Another question would be, does a session have to be replicated in it's
whole or could a protocol be used that does incremental (diff) changes?
Would the overhead to find out what has changed be higher than just sending
the whole bunch of objects again? Difficult questions as we don't know how
big the session objects are or how often and how much they change in
advance.

But I think it is worthwhile putting some effort in clustering as this would
help keeping tomcats leading role as an application server and further
extend it to mission crtitical systems where today there is no other choice
than using commercial products that have decent clustering capabilities.

Hope to get your thoughts!

Cheers, Mika


----- Original Message -----
From: "jean-frederic clere" <jfrederic.clere@fujitsu-siemens.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Tuesday, November 06, 2001 10:35 AM
Subject: Re: Tomcat 4 Cluster -- plans?


> GOMEZ Henri wrote:
> >
> > Some comment here about clustering support
> > from ideas I've got to add this kind of
> > support to Tomcat 3.3 also via mod_jk/ajp14,
> > having sus a perfect match for Apache -> Tomcat
> > farms allready supported by mod_jk/ajp13.
> >
> > a) When session is serialized the data could be
> >    send back to Apache server for example
> >    with reply. The web-server keep the serialized
> >    data (in any db supported by the server like db3,
> >    or in mmap file...). When session data is updated
> >    the whole stuff is resent to Apache which will
> >    replace it with the new one.
> >
> >    When mod_jk detect that a tomcat is down, it locate
> >    another tomcat on the farm and if session data
> >    is available for that request, send the serialized
> >    data together with the request.
> >    On reception, the tomcat create the session and
> >    feed it with serialized data.
> >
> > b) Another possibility is that Tomcat write the serialized
> >    session data to a SQL server for example, and send back
> >    a key to Apache server.
> >
> >    In case of failure, mod_jk send that key to the new tomcat
> >    which will create the session and feed it with data from
> >    the SQL backend.
>
>
> Another possibility would be that the TC stores the context in share
filesystem
> at the end of each reponse.
> The context has to be reloaded from the file when starting the request.
> That way all the TC's are identical for the sessions.
> I/O are cached by the operating system. "Shared memory" could be used if
the
> TC's are on the same machine.
>
> >
> > This solution avoid complexity and platform problems with
> > multicast sockets. Using a SQL backend or just sending
> > stuff to WebServer is a choice, both solution could be
> > implemented and tested.
> >
> > The housekeeping will be easy.
> > When a session has expired or explicitly dropped, we just have
> > to delete the SQL record and/or send a clear session command
> > (with list of session key to be removed) to web-server with
> > the next reply sent back.
> >
> > The overhead in both case is serialization of session data,
> > and transmitting data/key in case a) and key in case b).
>
> Note that in b) you have to store the session... If the TC's are in
different
> machines you do not save that much.
>
> >
> > Of of the advantage of SQL solution, is that it could works
> > on X * Web-Server -> Y * Tomcat architecture.
> >
> > In that case we could add the KEY somewhere on HTTP header for example.
> > When a tomcat engine discover that key, and detect that there is
> > no session loaded on memory, it will create the session automatically
> > after getting (successfully) the serialized data (and of course if the
> > session is still valid).
> >
> > table could be :
> >
> > string key;
> > date   validity;
> > blob   serializeddata;
> >
> > What do you think of it ?
>
> Is the key related to the sessionid? Because the context to restore is the
> context of the session.
>
> >
> > -
> > Henri Gomez                 ___[_]____
> > EMAIL : hgomez@slib.fr        (. .)
> > PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> >
> > >-----Original Message-----
> > >From: Mika Goeckel [mailto:mika@stepstone.de]
> > >Sent: Monday, November 05, 2001 1:08 AM
> > >To: tomcat-dev@jakarta.apache.org
> > >Subject: Tomcat 4 Cluster -- plans?
> > >
> > >
> > >Hi,
> > >
> > >I've browsed through org.apache.catalina.cluster and have some
> > >ideas about
> > >further development there. Before I start to mess around with
> > >it I would
> > >like to ask if anyone here already has started working.
> > >My superficial inspection gives me the impression that sessions are
> > >replicated (through the MulticastSender/Receiver) to all
> > >cluster members.
> > >This is propably the savest way doing it, but leads to a lot
> > >of replications
> > >that will never been used in clusters with more than two nodes. Afaik
> > >WebLogic replicates to only one other instance which means
> > >that the cluster
> > >can provide fail over if one node goes down.
> > >I'd like to think how that can be achieved.
> >
> > --
> > To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:tomcat-dev-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message