Comparing distributed members IDs for equivalency.

[Jens Deppe <je...@apache.org>]

Hi,

I'm finding that different components in Geode represent the member ID
differently. For example, some MBeans might show the member as
*10.118.33.250(server1:27254)<ec><v1>:1025* whereas the DistributionManager
might show the member as *deppe-mbp(server1:27254)<ec><v1>:1025*.

Unfortunately there are (many?) places where member equivalency is tested
by comparing the string representations. In this case, it fails.

Do we have any code that checks equivalency based on the string
representation of a member? I don't see anything in
InternalDistributedMember.

As an aside, there is some indication that this may only be relevant on Mac
OS and not on Linux variants.

Thanks
--Jens

Re: Comparing distributed members IDs for equivalency.

[Dan Smith <ds...@pivotal.io>]

Why are we comparing the string representation? That seems like a bug to me.

-Dan

On Tue, Mar 15, 2016 at 8:45 AM, Jens Deppe <je...@apache.org> wrote:

> Hi,
>
> I'm finding that different components in Geode represent the member ID
> differently. For example, some MBeans might show the member as
> *10.118.33.250(server1:27254)<ec><v1>:1025* whereas the DistributionManager
> might show the member as *deppe-mbp(server1:27254)<ec><v1>:1025*.
>
> Unfortunately there are (many?) places where member equivalency is tested
> by comparing the string representations. In this case, it fails.
>
> Do we have any code that checks equivalency based on the string
> representation of a member? I don't see anything in
> InternalDistributedMember.
>
> As an aside, there is some indication that this may only be relevant on Mac
> OS and not on Linux variants.
>
> Thanks
> --Jens
>

Re: Comparing distributed members IDs for equivalency.

[Bruce Schuchardt <bs...@pivotal.io>]

The two strings being compared in that test are both coming from 
InetAddress.getCanonicalHostName().

Le 3/15/2016 11:16 AM, Jinmei Liao a écrit :
> at
> com.gemstone.gemfire.LonerDMJUnitTest.testMemberId(LonerDMJUnitTest.java:171)
> org.junit.ComparisonFailure:
> Expected :localhost
> Actual   :10.118.33.244

Re: Comparing distributed members IDs for equivalency.

[Jinmei Liao <ji...@pivotal.io>]

In the IntelliJ on my mac, I just right click the geode-core module and ran
all the tests in it, the first few failures seem to be related to this ID
check failure.

at
com.gemstone.gemfire.LonerDMJUnitTest.testMemberId(LonerDMJUnitTest.java:171)
org.junit.ComparisonFailure:
Expected :localhost
Actual   :10.118.33.244

at
com.gemstone.gemfire.cache.client.ClientCacheFactoryJUnitTest.test000Defaults(ClientCacheFactoryJUnitTest.java:99)
java.lang.AssertionError:
Expected :[jiliao-mbpro/127.0.0.1:40404] Actual :[
10.118.33.244/10.118.33.244:40404]

at
com.gemstone.gemfire.cache.client.ClientCacheFactoryJUnitTest.test005SecureUserDefaults(ClientCacheFactoryJUnitTest.java:242)
java.lang.AssertionError: Expected :[jiliao-mbpro/127.0.0.1:40404] Actual :[
10.118.33.244/10.118.33.244:40404]

On Tue, Mar 15, 2016 at 9:53 AM, Bruce Schuchardt <bs...@pivotal.io>
wrote:

> InternalDistributedMember.toString() will use a host name if
> SocketCreator.resolve_dns is set to true.  Otherwise it uses a numeric IP
> address.
>
> resolve_dns is set to false if network partition detection is enabled in
> order to avoid contacting a DNS server, which has been known to hang when
> there are network problems and cause servers to not shut down.
>
> So, if an IDM.toString() is built in a JVM that has resolve_dns set to
> true it will not be equal to one from a JVM where it was set to false.
> This may be what is affecting you.
>
>
>
> Le 3/15/2016 8:45 AM, Jens Deppe a écrit :
>
>> Hi,
>>
>> I'm finding that different components in Geode represent the member ID
>> differently. For example, some MBeans might show the member as
>> *10.118.33.250(server1:27254)<ec><v1>:1025* whereas the
>> DistributionManager
>> might show the member as *deppe-mbp(server1:27254)<ec><v1>:1025*.
>>
>> Unfortunately there are (many?) places where member equivalency is tested
>> by comparing the string representations. In this case, it fails.
>>
>> Do we have any code that checks equivalency based on the string
>> representation of a member? I don't see anything in
>> InternalDistributedMember.
>>
>> As an aside, there is some indication that this may only be relevant on
>> Mac
>> OS and not on Linux variants.
>>
>> Thanks
>> --Jens
>>
>>
>


-- 
Cheers

Jinmei

Re: Comparing distributed members IDs for equivalency.

[Nitin Lamba <nl...@apache.org>]

+1

Not sure if my finding is related to this issue but every time I start a
locator on my mac without specifying bind address, the Locator and Manager
services do not bind to localhost consistently. Following are the steps to
reproduce:

gfsh> start locator --name=locator
...
gfsh> exit

Start gfsh again and reconnect:
gfsh>connect
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=192.168.1.5, port=1099] ..
Successfully connected to: [host=192.168.1.5, port=1099]

As you can see, Manager binds to an active network interface whereas
Locator binds to localhost. So, if I move from office to home, the service
gets dropped and I have to kill/restart the process. Not a big deal for
production/ linux installs but an annoyance for developers on Mac.

Let me know if I should file a separate JIRA for this.

Thanks,
Nitin

On Thu, Mar 17, 2016 at 8:50 AM, Jens Deppe <jd...@pivotal.io> wrote:

> I'd like to propose having the *member's local hostname* only be an IP
> address - see the change in SocketCreator here:
> https://reviews.apache.org/r/44961/diff/1#0
>
> I'll repeat some of my review comments here.
>
> On Mac OS the hostname is not tied to a particular address like other *nix
> systems. A typical *nix system might have the hostname defined in
> /etc/hosts or resolvable via DNS. The hostname/IP mapping remains fixed and
> consistent. Under Mac OS (and at least under Java) the
> InetAddress.getLocalHost call is not deterministic and may associate the
> local hostname with any of the hosts' currently assigned IP addresses.
> There is no mapping done through /etc/hosts. This also means that given a
> localhost InetAddress, a reverse DNS lookup of the address will likely
> fail.
>
> By using only the IP address for the local hostname, the member ID remains
> consistent.
>
> --Jens
>
> On Tue, Mar 15, 2016 at 9:53 AM, Bruce Schuchardt <bs...@pivotal.io>
> wrote:
>
> > InternalDistributedMember.toString() will use a host name if
> > SocketCreator.resolve_dns is set to true.  Otherwise it uses a numeric IP
> > address.
> >
> > resolve_dns is set to false if network partition detection is enabled in
> > order to avoid contacting a DNS server, which has been known to hang when
> > there are network problems and cause servers to not shut down.
> >
> > So, if an IDM.toString() is built in a JVM that has resolve_dns set to
> > true it will not be equal to one from a JVM where it was set to false.
> > This may be what is affecting you.
> >
> >
> > Le 3/15/2016 8:45 AM, Jens Deppe a écrit :
> >
> >> Hi,
> >>
> >> I'm finding that different components in Geode represent the member ID
> >> differently. For example, some MBeans might show the member as
> >> *10.118.33.250(server1:27254)<ec><v1>:1025* whereas the
> >> DistributionManager
> >> might show the member as *deppe-mbp(server1:27254)<ec><v1>:1025*.
> >>
> >> Unfortunately there are (many?) places where member equivalency is
> tested
> >> by comparing the string representations. In this case, it fails.
> >>
> >> Do we have any code that checks equivalency based on the string
> >> representation of a member? I don't see anything in
> >> InternalDistributedMember.
> >>
> >> As an aside, there is some indication that this may only be relevant on
> >> Mac
> >> OS and not on Linux variants.
> >>
> >> Thanks
> >> --Jens
> >>
> >>
> >
>

Re: Comparing distributed members IDs for equivalency.

[Jens Deppe <jd...@pivotal.io>]

I'd like to propose having the *member's local hostname* only be an IP
address - see the change in SocketCreator here:
https://reviews.apache.org/r/44961/diff/1#0

I'll repeat some of my review comments here.

On Mac OS the hostname is not tied to a particular address like other *nix
systems. A typical *nix system might have the hostname defined in
/etc/hosts or resolvable via DNS. The hostname/IP mapping remains fixed and
consistent. Under Mac OS (and at least under Java) the
InetAddress.getLocalHost call is not deterministic and may associate the
local hostname with any of the hosts' currently assigned IP addresses.
There is no mapping done through /etc/hosts. This also means that given a
localhost InetAddress, a reverse DNS lookup of the address will likely fail.

By using only the IP address for the local hostname, the member ID remains
consistent.

--Jens

On Tue, Mar 15, 2016 at 9:53 AM, Bruce Schuchardt <bs...@pivotal.io>
wrote:

> InternalDistributedMember.toString() will use a host name if
> SocketCreator.resolve_dns is set to true.  Otherwise it uses a numeric IP
> address.
>
> resolve_dns is set to false if network partition detection is enabled in
> order to avoid contacting a DNS server, which has been known to hang when
> there are network problems and cause servers to not shut down.
>
> So, if an IDM.toString() is built in a JVM that has resolve_dns set to
> true it will not be equal to one from a JVM where it was set to false.
> This may be what is affecting you.
>
>
> Le 3/15/2016 8:45 AM, Jens Deppe a écrit :
>
>> Hi,
>>
>> I'm finding that different components in Geode represent the member ID
>> differently. For example, some MBeans might show the member as
>> *10.118.33.250(server1:27254)<ec><v1>:1025* whereas the
>> DistributionManager
>> might show the member as *deppe-mbp(server1:27254)<ec><v1>:1025*.
>>
>> Unfortunately there are (many?) places where member equivalency is tested
>> by comparing the string representations. In this case, it fails.
>>
>> Do we have any code that checks equivalency based on the string
>> representation of a member? I don't see anything in
>> InternalDistributedMember.
>>
>> As an aside, there is some indication that this may only be relevant on
>> Mac
>> OS and not on Linux variants.
>>
>> Thanks
>> --Jens
>>
>>
>

Re: Comparing distributed members IDs for equivalency.

[Bruce Schuchardt <bs...@pivotal.io>]

InternalDistributedMember.toString() will use a host name if 
SocketCreator.resolve_dns is set to true.  Otherwise it uses a numeric 
IP address.

resolve_dns is set to false if network partition detection is enabled in 
order to avoid contacting a DNS server, which has been known to hang 
when there are network problems and cause servers to not shut down.

So, if an IDM.toString() is built in a JVM that has resolve_dns set to 
true it will not be equal to one from a JVM where it was set to false.  
This may be what is affecting you.


Le 3/15/2016 8:45 AM, Jens Deppe a écrit :
> Hi,
>
> I'm finding that different components in Geode represent the member ID
> differently. For example, some MBeans might show the member as
> *10.118.33.250(server1:27254)<ec><v1>:1025* whereas the DistributionManager
> might show the member as *deppe-mbp(server1:27254)<ec><v1>:1025*.
>
> Unfortunately there are (many?) places where member equivalency is tested
> by comparing the string representations. In this case, it fails.
>
> Do we have any code that checks equivalency based on the string
> representation of a member? I don't see anything in
> InternalDistributedMember.
>
> As an aside, there is some indication that this may only be relevant on Mac
> OS and not on Linux variants.
>
> Thanks
> --Jens
>