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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
