geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Web State Replication... (long)
Date Fri, 31 Oct 2003 08:00:14 GMT
gianny DAMOUR wrote:

> Jules Gosnell wrote:
>>> 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:
>> ?? - If you don't, it will continue to deliver requests to the node 
>> that the session used to be at, not the node that it is currently at. 
>> This is bad news. You will either have to forward/redirect (clumsy), 
>> migrate the session back to this node (wasted cycles/bandwidth/time) 
>> or continue without the session (failure).
> No: it tries the primary. The primary is not available. It then tries 
> another available server. This server can be the secondary or not. One 
> does not care about the migration process because this available 
> server will request to the secondary the session attached to the 
> incoming request. At the end of the day, the lb is aware only of the 
> available servers.

OK - you are talking about failover - in that case I agree.

I thought you were just talking generally about migration.

If you just migrate state in order to balance it around the cluster, you 
will need some way of syncing this new distribution with the lb...

So we see eye to eye :-)


>>> 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.
>> If you had a loadbalancer that did this sort of thing, then there is 
>> no reason why you shouldn't encode a 'failover-list' into the session 
>> id, or extra cookie/url-param etc.... - I believe that this is a 
>> strategy use by WebLogic, but they have a custom Apache module... You 
>> might be able to extend e.g. mod_backhand to do this, or perhaps more 
>> major surgery on another module might achieve it...
> Indeed, WebLogic works like this in the case of a soft lb. In the case 
> of an hardware load-balancing, WebLogic implements what I have just 
> described: send to an available server and then this server is in 
> charge of requesting the session to the secondary.
>> Hope that helps,
> Thanks for that. I start to understand the design.
> Cheers,
> Gianny
> _________________________________________________________________
> Trouvez l'âme soeur sur MSN Rencontres !

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message