tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Olliver" <a...@slyfrog.com>
Subject RE: Tomcat 4 Cluster -- plans?
Date Tue, 06 Nov 2001 23:48:58 GMT
For clustering I think Realm data must be taken into account as well as
session data, in order for secured apps to fail over without need for
re-authentication - otherwise we will all need to continue life with our
home-grown access control implementations, which would be a shame
considering how easy Realms make things.

Andy


-----Original Message-----
From: jfclere@vtxrm2.bcn.fsc.net [mailto:jfclere@vtxrm2.bcn.fsc.net]On
Behalf Of jean-frederic clere
Sent: 06 November 2001 11:59
To: Tomcat Developers List
Subject: Re: Tomcat 4 Cluster -- plans?


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>


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