tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: [feedback request] session replication
Date Fri, 03 Mar 2006 23:26:15 GMT
Leon Rosenberg wrote:
> Hello Filip,
> very interesting proporsal indeed. May I point you to some importand
> use-cases and ask whether your proporsal has solutions for it.
> 1. Poviding an easy way to customize diffs.
> As far as I understand customizable diffs are possible by a) patching
> the StandardSession or b) configuring alternative SessionManager which
> would create a wrapper to the StandardSession. Still I'd prefer an
> easier way, for example a DiffCreator object inside the session which
> can be replaced upon session creating.
> The background of the question is following:
> we have a large webfarm with huge traffic on it. Our sessions are
> partly heavyweght, since we using them for caching (we have much to
> much memory in the tomcat and want to use it). For example we are
> caching search results (very heavyweight) which are provided by a
> third-party search engine. In case a use just switches the view or
> navigate in cached parts of the search result, they are replied from
> cache reducing load on the third-party system. In case of a server
> crash and the failover to another server we would accept loosing the
> cached version in favour of reducing the traffic. Therefore a
> customization would be very useful.
This scenario sounds like you shouldn't use the session as cache, 
implement a cache object that does the same thing.
but point taken, you want a way to customize the diffs, my guess is that 
you could have a pluggable diff object that attaches to the session.
This object can be configured through server.xml (global) or context.xml 
(per webapp)

> 2. Session sharing between different webapps.
> Following use-case: As soon as the user submits personal information
> it's sent over https instead of http to secure it from the
> man-in-the-middle. Our https is handled by the loadbalancer
> (hardware), so we aren't able to provide https for every user
> operation. The application which is handling personal data contains
> all the same classes as the primary application, but another
> configuration, so it can be considered a different webapps. For
> tracking purposes we need data from users primary session, which we
> can't access in the https application. It would be very cool (and
> actually a task in my bugzilla account at work) to provide a service
> which could maintain a part of the session centralized and allow other
> servers/webapps to get this sessions data.
easier way to do this would be to create a centralized cache, and put it 
in <tomcat>/shared/lib/
This might be out of scope for Tomcat, and out of scope for replication 
for sure.

> 3. Controlled failover:
> In order to make soft-releases and maintainance (without logging out
> the user) it would be very cool to transfer a session from one server
> to another and back.
> Use case:
> The webfarm consists of two servers, A and B. Admin issues a command
> to server A notto accept new sessions anymore. Server A (customizable
> code of course) rewrites the loadbalancer cookie to point to server B.
> User makes next request and comes to server B which then gets the
> session from A. After all A sessions expire (or a timeout) server A
> goes down for maintainance. After Server A is back up again and the
> game continues with B.
This is automatic. It will happen exactly the way you describe. The way 
the LazyReplicatedMap works is as follows:
1. Backup node fails -> primary node chooses a new backup node
2. Primary node fails -> since Tomcat doesn't know which node the user 
will come to their
   next http request, nothing is done.
   When the user makes a request, and the session manager says 
LazyMap.getSession(id) and that session is not yet on the server,
   the lazymap will request the session from the backup server, load it 
up, set this node as primary.
   that is why it is called lazy, cause it wont load the session until 
it is actually needed, and because it doesn't know what node will become 
primary, this is decided by the load balancer.
> best regards
> Leon
> P.S. One more question... If I understood your correctly you plan to
> share the session with exact one other server. I haven't found
> anything about central replication service in your mail, so how is the
> server deciding which is he's replication partner? Kind of random
> algorythm or broadcast request? Please enlight me :-)
the algorithm is pluggable, a tomcat A server can decide back up all 
sessions to the same node, tomcat B, or tomcatA can distribute its 
sessions round robin to B,C,D,...

or a more sophisticated and complicated mechanism can be developed, but 
probably not needed and it doesn't adhere to ;)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message