[infinispan-dev] Proposal: ISPN-1394 Manual rehashing in 5.2

Erik Salter an1310 at hotmail.com
Tue Jan 31 11:21:15 EST 2012


...such as bringing up a backup data center.

-----Original Message-----
From: infinispan-dev-bounces at lists.jboss.org
[mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Bela Ban
Sent: Tuesday, January 31, 2012 11:18 AM
To: infinispan-dev at lists.jboss.org
Subject: Re: [infinispan-dev] Proposal: ISPN-1394 Manual rehashing in 5.2

I cannot volunteer either, but I find it important to be done in 5.2 !

Unless rehashing works flawlessly with a large number of nodes joining 
at the same time, I think manual rehashing is crucial...



On 1/31/12 5:13 PM, Sanne Grinovero wrote:
> On 31 January 2012 16:06, Bela Ban<bban at redhat.com>  wrote:
>> This is essentially what I suggested at the Lisbon meeting, right ?
>
> Yes!
>
>> I think Dan had a design wiki on this somewhere...
>
> Just rising it here as it was moved to 6.0, while I think it deserves
> a dedicated thread to better think about it. If it's not hard, I think
> it should be done sooner.
> But while I started the thread to wake up the brilliant minds, I can't
> volunteer for this to make it happen.
>
> Sanne
>
>>
>>
>> On 1/31/12 4:53 PM, Sanne Grinovero wrote:
>>> I think this is an important feature to have soon;
>>>
>>> My understanding of it:
>>>
>>> We default with the feature off, and newly discovered nodes are
>>> added/removed as usual. With a JMX operatable switch, one can disable
>>> this:
>>>
>>> If a remote node is joining the JGroups view, but rehash is off: it
>>> will be added to a to-be-installed view, but this won't be installed
>>> until rehash is enabled again. This gives time to add more changes
>>> before starting the rehash, and would help a lot to start larger
>>> clusters.
>>>
>>> If the [self] node is booting and joining a cluster with manual rehash
>>> off, the start process and any getCache() invocation should block and
>>> wait for it to be enabled. This would need of course to override the
>>> usually low timeouts.
>>>
>>> When a node is suspected it's a bit a different story as we need to
>>> make sure no data is lost. The principle is the same, but maybe we
>>> should have two flags: one which is a "soft request" to avoid rehashes
>>> of less than N members (and refuse N>=numOwners ?), one which is just
>>> disable it and don't care: data might be in a cachestore, data might
>>> not be important. Which reminds me, we should consider as well a JMX
>>> command to flush the container to the CacheLoader.
>>>
>>> --Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Bela Ban
>> Lead JGroups (http://www.jgroups.org)
>> JBoss / Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list