[infinispan-dev] DistributionManagerImpl.rehash()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] DistributionManagerImpl.rehash()

Bela Ban
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
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] DistributionManagerImpl.rehash()

Manik Surtani
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
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] DistributionManagerImpl.rehash()

Bela Ban
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
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] DistributionManagerImpl.rehash()

Manik Surtani
+1.

On 1 Feb 2011, at 07:54, Bela Ban wrote:

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

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev