+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 <[email protected]> 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 <[email protected]> > 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 > >> > >> > > >
