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
http://people.apache.org/~fhanik/kiss.html ;)
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
