[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