[infinispan-dev] DistributionManagerImpl.rehash()

Bela Ban bban at redhat.com
Tue Feb 1 02:54:02 EST 2011


When you're looking at this, can we remove or change the log statement 
about "JOIN / LEAVE detected; waiting for notification from XXX" ? There 
is no corresponding "notification received / not received", and it looks 
as if we're blocked on some notification...

Running Infinispan on RELAY, I found a major bug which causes {A, A/X 
(proxy to X),C} to be collapsed into {A,C}, e.g. if you use a HashSet 
(which is exactly what you do in the code mentioned below)...
Cheers,


On 2/1/11 8:18 AM, Manik Surtani wrote:
> This is a bug, but it isn't in handling joiners.  Join is a pull process, so existing members only detect joiners and log it - nothing "important" happens with the results of MembershipArithmetic.getMemberJoined().
>
> MembershipArithmetic.getMemberLeft(), OTOH, is important - and has a similar bug.  This is odd, because we also have MembershipArithmetic.getMembersLeft() (MembershipArithmetic.getMembersJoined()) - which return all affected members, not just the first one - but these seem unused for some reason.
>
> I'll investigate.  Thanks for pointing this out.
>
> Cheers
> Manik
>
> On 31 Jan 2011, at 14:25, Bela Ban wrote:
>
>> I see that this method calls MembershipArithmetic.getMemberJoined(),
>> which returns the newly joined member. This is done by removing the
>> existing members from the new members, and returning the first element
>> of the remaining list.
>>
>> However, when we have view V1={A,B} and V2={A,B,C,D}, then the method
>> getMemberJoined() returns C, but skips D.
>>
>> It seems to me that this logic is based on the assumption that JGroups
>> only ever joins and removes 1 member at a time, but this is not correct,
>> as JGroups can join multiple new members, or remove multiple members at
>> once, too.
>>
>> Can you guys take a look ?


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss


More information about the infinispan-dev mailing list