[infinispan-dev] Asymmetric caches and manual rehashing design

[Bela Ban]

Yes, the idea was to have a bunch of conditions ORed together, so if one 
of them was true a rebalance would occur.

E.g.:
- Try to see if a rebalance is needed every 5 seconds. When there's a 
view change, reset the timer, so it'll fire 5 secs from now. This would 
prevent rebalancing to happen in a high churn period, e.g. when 10 nodes 
join

- When N JOINs have been received

- When M LEAVES have been received

- On a MERGE



On 9/29/11 6:14 PM, Mircea Markus wrote:
>
> On 29 Sep 2011, at 08:06, Bela Ban wrote:
>
>>
>>
>> On 9/28/11 4:24 PM, Mircea Markus wrote:
>>> Nice stuff.
>>>
>>> Some q:
>>>
>>> - When a node CM that has c1 and c2 caches running on it goes down, you'll end up having  REQUEST_LEAVE(c1) and REQUEST_LEAVE(c2) at the same time. Is this handled in serial or in parallel?
>>
>>
>> I don't think any requests should be sent in this case: the current
>> coordinator should add the LEAVE(s) into its queue, as if it indeed did
>> receive 2 LEAVE requests. This may or may not lead to rebalance,
>> depending on the rebalance policy (e.g. JOINS are queued, but LEAVES and
>> MERGES trigger a rebalance immediately).
> Makes sense.
> On a side note, I only see a point in having LEAVES policy set to QUEUE (vs immediate) if there's an controlled system shutdown. Otherwise the JOINS should be handled on an immediate bases: that's in order to quickly react to topology node crashes.  So IMO we also need the hooks to switch between IMMEDIATE vs QUEUE policy at runtime.


-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat