geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: Web State Replication... (long)
Date Thu, 30 Oct 2003 22:50:15 GMT
Jules Gosnell wrote:
>As for the amount of state that each node carries, there should not be a 
>problem in each node specifying a higher or lower threshold at which to 
>migrate or passivate sessions (i.e. number of active sessions it can 
>carry). Although, as discussed in the previous posting, you need to be able 
>to tell your lb about migration.
I see. I understand why you need to tell your lb about migrations and, if I 
understand it correctly, this is mainly an optimization. However, you are 
not compeled to keep the lb aware of migrations:

I assume that in the cookies or in the URL will be embedded the identifiers 
of the replica. If the primary node fails, the lb can try any available 
servers. This server is part of the domain and by using the cookies or the 
URL of the incoming request, it can request to the replica the session 
attached to the incoming request.

What is really interesting is that this server becomes now the primary and 
the other replica do not need to be updated.

>My idea here is to provide a pluggable 'sort()' strategy, which the 
>deployer can provide.

>>- Is it not an overhead to have b-1 replica? AFAIK, a single secondary 
>>should be enough.
>This will be a deployment-time decision. I simply chose b=3 as a common 
>example - I am sure b=2 will also be widely used.


Trouvez l'âme soeur sur MSN Rencontres

View raw message