geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [clustering] automatic partitoning, state bucketing, etc... (long)
Date Sun, 17 Aug 2003 23:54:57 GMT
Jeremy Boynes wrote:

>Not sure this is the right track - I brain dumped on the wiki

I agree with everything you have said (the cheque's in the post - 
right?), except the last bit:

IMNSHO these are independent of the approach used to replicate state, 
but should be driven by other concerns. For example, I may use 
partitions to determine to which nodes an application gets deployed, 
which obviously interacts with load-balancing in that I do not want to 
have requests directed to nodes where an app is not running.

However, as I hope I illustrated above, the policy for storing, 
replicating and locating state does not really depend on the partition 

I figure that we are talking about two different and orthogonal types of 
partition here.

I'm happy to call the way that nodes are linked into buddy-groups 
(groups of peers that store replicated state for each other) something 
other than 'partition', if we want to reserve that term for some sort of 
cluster management concept, but you do agree that these structures 
exist, do you not ? regardless of what they are called, otherwise you do 
not scale, as we have all agreed.

As for loadbalancer configuration I think this will draw upon both 
'jeremy-partition' and 'jules-buddy-group' status as :

- you only want to balance requests for a webapp to nodes on which it is 
- you only want to fail-over requests to other nodes in the same 
buddy-group as the failed node

if you can do the latter you can avoid cluster-wide logic for findg and 
migrating sessions from remote nodes to the one receiving the request, 
because you can guarantee that the session is already there.

Are we getting closer ?


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

View raw message