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 Thu, 30 Oct 2003 17:29:04 GMT
gianny DAMOUR wrote:

> Hello,
> Just a couple of questions regarding this design:
> - Is it possible to configure the weight of a node? If yes, is the 
> same auto-partitioning policy applicable? My concern is that a 
> "clockwise" policy may add a significant load on nodes hosted by low 
> spec hosts. 

sure - there is no reason why it should not be.

The load balancer should be able to apply weightings in it's balancing 
of stateless (without session) requests.

The more closely integrated with the cluster, the more informed these 
decisions will be,

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. Alternatively, we can just 
dynamically turn down the weighting for a smaller node so that the lb 
sends requests that might create sessions to it less frequently, until 
sessions die off, then we can turn it up again.

Requests going to existing sessions will not be affected by this as 
their affinity overrides any weighting that is done.

> - I have the feeling that one can not configure a preferred 
> replication group for primary sessions of a specific node: if four 
> nodes are available, I would like to configure that sessions of the 
> first node should be replicated by the third node, if available, or 
> the fourth one. 

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

The class will be responsible for sorting, inserting and removing nodes 
from the 'clock', so it will have complete control over which nodes back 
up which other nodes (within the constraints of the clock arrangement). 
Of course, if you don't keep the order as steady as possible, you will 
incur migration costs which you really want to avoid.

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


> Cheers,
> Gianny
> _________________________________________________________________
> MSN Search, le moteur de recherche qui pense comme vous !  

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

View raw message