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