tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: Tomcat 4 Cluster -- plans?
Date Tue, 06 Nov 2001 11:58:33 GMT
Mika Goeckel wrote:
> 
> 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?

Sure that is problem, we have to solve it...

> 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.

Apache needs to identify the session that belongs to the request and reloads or
causes the reload of the corresponding context.

> 
> 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.

That shows that there should not be several copies of the context , or that the
most up to date one must be easy to find.

> 
> 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>

--
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