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 Sat, 04 Mar 2006 00:34:35 GMT
for very large clusters, you use the same mechanism, except, instead of 
distributing the entire session map, the backup node info is stored in a 


> If we would store the result-set (list of already created beans) in
> the session, we'd have to store them twice, once in the "cache" and
> once in request for presentation. However, a pluggable diff object
> would be great!
how you store it, once or twice is up to you, and how you code your app. 
if you are storing it twice then that is a flaw in your programming, not 
in tomcat nor in the session replication.

> Btw, another point: The object/handler/whatever which decides whether
> a session create event should be distributed at all should be
> configurable/replaceable too.
> Background: most or at least many hardware loadbalancer use urls for
> service health monitoring. They do not send any cookies back, so in
> fact each heartbit creates a new session. Our lb + failover lb are
> sending heartbits each 8 seconds each. With session timeout of 30
> minutes we always have 450 active lb sessions on each server.
> Distributing those sessions should be considered spam and waste of
> network resources :-)
as mentioned, you can choose cookie or distributed map. when you use the 
cookie logic, you still need to cancel out the primary cookie in case 
the lb did a false positive.

> In case primary node knows, that it will go down in near future and
> should send all his users away, it could stop accepting new requests
> and redirect old users directly to the backup node(s). That way the
> performance risk of getting sessions cross over the network could be
> reduced.
> What do you think about it?
this would be implementing code that is not needed. solving a problem 
that is already solved doesn't help anyone.

>> ;)
> I fully agree with the KISS principle, and follow it in my job and all
> projects, that's why we never use anything we don't need, like
> app-servers, or-mappers and such, until one proves, that using the
> thing make the live really easier and not complicated.
> Therefore I understand that implementing support for everything
> everyone need and keeping the code simple are contrarian goals, but
> making the code fine-graned and elements exchangeable wouldn't violate
> KISS, would it?
it would only violate it if you the features are never used, and 
everyone sticks with the default. then you have code that is not in place.
I usually don't write the code until there is an expressed need for it, 
and I can't get that expressed need until people say they dont like the 
default impl.

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

View raw message