tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
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 
cookie.

Filip


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

>   
>> http://people.apache.org/~fhanik/kiss.html ;)
>>     
>
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message