ZooKeeper
  1. ZooKeeper
  2. ZOOKEEPER-1256

ClientPortBindTest is failing on Mac OS X

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.5.3, 3.6.0
    • Component/s: tests
    • Labels:
      None
    • Environment:

      Mac OS X

    • Hadoop Flags:
      Reviewed

      Description

      ClientPortBindTest is failing consistently on Mac OS X.

      1. ClientPortBindTest.log
        9 kB
        Daniel Gómez Ferro
      2. ZOOKEEPER-1256.patch
        1 kB
        Flavio Junqueira
      3. ZOOKEEPER-1256.patch
        0.7 kB
        Daniel Gómez Ferro
      4. ZOOKEEPER-1256.patch
        2 kB
        Daniel Gómez Ferro
      5. ZOOKEEPER-1256v2.patch
        0.7 kB
        Camille Fournier
      6. ZOOKEEPER-1256v3.patch
        0.9 kB
        Camille Fournier

        Issue Links

          Activity

          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12501055/ZOOKEEPER-1256.patch
          against trunk revision 1189318.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/693//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501055/ZOOKEEPER-1256.patch against trunk revision 1189318. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/693//console This message is automatically generated.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12501057/ZOOKEEPER-1256.patch
          against trunk revision 1189318.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/694//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/694//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/694//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501057/ZOOKEEPER-1256.patch against trunk revision 1189318. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/694//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/694//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/694//console This message is automatically generated.
          Hide
          Patrick Hunt added a comment -

          I don't think we can just remove this, see "Textual representation of IPv6 scoped addresses" here:
          http://download.oracle.com/javase/1,5.0/docs/api/java/net/Inet6Address.html

          What is the failure you are seeing? Do you have ipv6 address or ipv4 on your loopback interface? If ipv6 are they scoped?

          Show
          Patrick Hunt added a comment - I don't think we can just remove this, see "Textual representation of IPv6 scoped addresses" here: http://download.oracle.com/javase/1,5.0/docs/api/java/net/Inet6Address.html What is the failure you are seeing? Do you have ipv6 address or ipv4 on your loopback interface? If ipv6 are they scoped?
          Hide
          Daniel Gómez Ferro added a comment -

          I added a log printing the bind address with the scope: fe80:0:0:0:0:0:0:1%1
          And this is the address NIOServerCnxnFactory tries to bind to: /fe80:0:0:0:0:0:0:1%0:11221

          If we remove the scope it tries to use a different one and it fails with java.net.BindException: Can't assign requested address

          Show
          Daniel Gómez Ferro added a comment - I added a log printing the bind address with the scope: fe80:0:0:0:0:0:0:1%1 And this is the address NIOServerCnxnFactory tries to bind to: /fe80:0:0:0:0:0:0:1%0:11221 If we remove the scope it tries to use a different one and it fails with java.net.BindException: Can't assign requested address
          Hide
          Daniel Gómez Ferro added a comment -

          From your link I understand the scoped IPV6 address is valid:

          The textual representation of IPv6 addresses as described above can be extended to specify IPv6 scoped addresses.

          The general format for specifying the scope_id is the following:
          IPv6-address%scope_id

          So what's wrong is removing it, no?

          Show
          Daniel Gómez Ferro added a comment - From your link I understand the scoped IPV6 address is valid: The textual representation of IPv6 addresses as described above can be extended to specify IPv6 scoped addresses. The general format for specifying the scope_id is the following: IPv6-address%scope_id So what's wrong is removing it, no?
          Hide
          Patrick Hunt added a comment -

          Odd. I just tried playing with IPV6 only on my lo device, using various scopes and it works for me both with and without this patch. I vaguely remember adding this line because some issue found during testing, but I can't reproduce. I'll go ahead and commit this, we'll see if anyone finds it again or not. Thanks Daniel!

          Show
          Patrick Hunt added a comment - Odd. I just tried playing with IPV6 only on my lo device, using various scopes and it works for me both with and without this patch. I vaguely remember adding this line because some issue found during testing, but I can't reproduce. I'll go ahead and commit this, we'll see if anyone finds it again or not. Thanks Daniel!
          Hide
          Patrick Hunt added a comment -

          committed to trunk/3.5.0, thanks Daniel!

          Show
          Patrick Hunt added a comment - committed to trunk/3.5.0, thanks Daniel!
          Hide
          Hudson added a comment -

          Integrated in ZooKeeper-trunk #1347 (See https://builds.apache.org/job/ZooKeeper-trunk/1347/)
          ZOOKEEPER-1256. ClientPortBindTest is failing on Mac OS X (Daniel Gómez Ferro via phunt)

          phunt : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1189918
          Files :

          • /zookeeper/trunk/CHANGES.txt
          • /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ClientPortBindTest.java
          Show
          Hudson added a comment - Integrated in ZooKeeper-trunk #1347 (See https://builds.apache.org/job/ZooKeeper-trunk/1347/ ) ZOOKEEPER-1256 . ClientPortBindTest is failing on Mac OS X (Daniel Gómez Ferro via phunt) phunt : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1189918 Files : /zookeeper/trunk/CHANGES.txt /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ClientPortBindTest.java
          Hide
          Flavio Junqueira added a comment -

          We should have committed this one to the 3.4.3 branch. The same patch applies.

          Show
          Flavio Junqueira added a comment - We should have committed this one to the 3.4.3 branch. The same patch applies.
          Hide
          Flavio Junqueira added a comment -

          Is it ok if we prefer IPv4 stack in this test? I think it is, but I'm wondering if anyone has a different opinion.

          Does it work for you, Camille Fournier? You mentioned that this has been failing for you.

          Show
          Flavio Junqueira added a comment - Is it ok if we prefer IPv4 stack in this test? I think it is, but I'm wondering if anyone has a different opinion. Does it work for you, Camille Fournier ? You mentioned that this has been failing for you.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12816839/ZOOKEEPER-1256.patch
          against trunk revision 1750739.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3266//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3266//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3266//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12816839/ZOOKEEPER-1256.patch against trunk revision 1750739. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3266//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3266//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3266//console This message is automatically generated.
          Hide
          Camille Fournier added a comment -

          Hey Flavio Junqueira, so we're looking for the loopback host address here? I don't really understand what this test is trying to do exactly, but it looks like on line 64, if I change that from
          bindAddress = addrs.nextElement().getHostAddress(); to
          bindAddress = addrs.nextElement().getLoopbackAddress().getHostAddress();
          all is fine. So I'm just not sure, if we're looking for the loopback address, why we aren't specifically asking for that in the test? But this is not a part of the networking code that is super familiar to me. Anyway, that change fixes it for me locally.

          Show
          Camille Fournier added a comment - Hey Flavio Junqueira , so we're looking for the loopback host address here? I don't really understand what this test is trying to do exactly, but it looks like on line 64, if I change that from bindAddress = addrs.nextElement().getHostAddress(); to bindAddress = addrs.nextElement().getLoopbackAddress().getHostAddress(); all is fine. So I'm just not sure, if we're looking for the loopback address, why we aren't specifically asking for that in the test? But this is not a part of the networking code that is super familiar to me. Anyway, that change fixes it for me locally.
          Hide
          Flavio Junqueira added a comment -

          This test case was introduced in ZOOKEEPER-635. I think you're suggesting something like this:

          -        String bindAddress = null;
          -        Enumeration<NetworkInterface> intfs =
          -            NetworkInterface.getNetworkInterfaces();
          -        // if we have a loopback and it has an address use it
          -        while(intfs.hasMoreElements()) {
          -            NetworkInterface i = intfs.nextElement();
          -            if (i.isLoopback()) {
          -                Enumeration<InetAddress> addrs = i.getInetAddresses();
          -                if (addrs.hasMoreElements()) {
          -                    bindAddress = addrs.nextElement().getHostAddress();
          -                }
          -            }
          -        }
          +        String bindAddress = InetAddress.getLoopbackAddress().getHostAddress();
          +
          

          As I see it, it tests what it is supposed to, which is that the server binds to a specified port, but I'm not sure what the issue is with the IPv6 address.

          Show
          Flavio Junqueira added a comment - This test case was introduced in ZOOKEEPER-635 . I think you're suggesting something like this: - String bindAddress = null; - Enumeration<NetworkInterface> intfs = - NetworkInterface.getNetworkInterfaces(); - // if we have a loopback and it has an address use it - while(intfs.hasMoreElements()) { - NetworkInterface i = intfs.nextElement(); - if (i.isLoopback()) { - Enumeration<InetAddress> addrs = i.getInetAddresses(); - if (addrs.hasMoreElements()) { - bindAddress = addrs.nextElement().getHostAddress(); - } - } - } + String bindAddress = InetAddress.getLoopbackAddress().getHostAddress(); + As I see it, it tests what it is supposed to, which is that the server binds to a specified port, but I'm not sure what the issue is with the IPv6 address.
          Hide
          Flavio Junqueira added a comment -

          Hmm, something doesn't smell good here, the 4lw command to check that the server is up is going through:

          2016-07-08 18:53:14,561 [myid:] - INFO  [main:FourLetterWordMain@85] - connecting to fe80:0:0:0:0:0:0:1%lo0 11222
          2016-07-08 18:53:14,571 [myid:] - INFO  [NIOServerCxnFactory.AcceptThread:/fe80:0:0:0:0:0:0:1%lo0:11222:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /fe80:0:0:0:0:0:0:1%1:51215
          2016-07-08 18:53:14,649 [myid:] - INFO  [NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from /fe80:0:0:0:0:0:0:1%1:51215
          2016-07-08 18:53:14,656 [myid:] - INFO  [NIOWorkerThread-1:StatCommand@49] - Stat command output
          2016-07-08 18:53:14,658 [myid:] - INFO  [NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client /fe80:0:0:0:0:0:0:1%1:51215 (no session established for client)
          

          but when we try to instantiate the handle, it fails to open the socket:

          2016-07-08 18:53:14,686 [myid:fe80:0:0:0:0:0:0:1%lo0:11222] - ERROR [main-SendThread(fe80:0:0:0:0:0:0:1%lo0:11222):ClientCnxnSocketNIO@287] - Unable to open socket to fe80:0:0:0:0:0:0:1%lo0/fe80:0:0:0:0:0:0:1:11222
          
          Show
          Flavio Junqueira added a comment - Hmm, something doesn't smell good here, the 4lw command to check that the server is up is going through: 2016-07-08 18:53:14,561 [myid:] - INFO [main:FourLetterWordMain@85] - connecting to fe80:0:0:0:0:0:0:1%lo0 11222 2016-07-08 18:53:14,571 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:/fe80:0:0:0:0:0:0:1%lo0:11222:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /fe80:0:0:0:0:0:0:1%1:51215 2016-07-08 18:53:14,649 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from /fe80:0:0:0:0:0:0:1%1:51215 2016-07-08 18:53:14,656 [myid:] - INFO [NIOWorkerThread-1:StatCommand@49] - Stat command output 2016-07-08 18:53:14,658 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client /fe80:0:0:0:0:0:0:1%1:51215 (no session established for client) but when we try to instantiate the handle, it fails to open the socket: 2016-07-08 18:53:14,686 [myid:fe80:0:0:0:0:0:0:1%lo0:11222] - ERROR [main-SendThread(fe80:0:0:0:0:0:0:1%lo0:11222):ClientCnxnSocketNIO@287] - Unable to open socket to fe80:0:0:0:0:0:0:1%lo0/fe80:0:0:0:0:0:0:1:11222
          Hide
          Flavio Junqueira added a comment -

          I've dug a bit deeper and found that the issue is in StaticHostProvider.resolveAndShuffle. This call:

          InetAddress.getByAddress(address.getHostString(), resolvedAddress.getAddress())
          

          produces this InetAddress:

          fe80:0:0:0:0:0:0:1%lo0/fe80:0:0:0:0:0:0:1
          

          This address format apparently confuses my mac and connecting fails (but note that as I said above the 4lw command works in the same execution):

          2016-07-09 18:24:43,482 [myid:fe80:0:0:0:0:0:0:1%lo0:11222] - ERROR [main-SendThread(fe80:0:0:0:0:0:0:1%lo0:11222):ClientCnxnSocketNIO@287] - Unable to open socket to fe80:0:0:0:0:0:0:1%lo0/fe80:0:0:0:0:0:0:1:11222
          

          I tried replacing that line with the following two:

          InetAddress.getByAddress(resolvedAddress.getAddress());
          InetAddress.getByName(resolvedAddress.getHostAddress());
          

          which gives me the following respectively:

          /fe80:0:0:0:0:0:0:1
          /fe80:0:0:0:0:0:0:1%lo0
          

          The first one also fails, but the second works. It looks like it doesn't work without the scope id.

          Show
          Flavio Junqueira added a comment - I've dug a bit deeper and found that the issue is in StaticHostProvider.resolveAndShuffle . This call: InetAddress.getByAddress(address.getHostString(), resolvedAddress.getAddress()) produces this InetAddress: fe80:0:0:0:0:0:0:1%lo0/fe80:0:0:0:0:0:0:1 This address format apparently confuses my mac and connecting fails (but note that as I said above the 4lw command works in the same execution): 2016-07-09 18:24:43,482 [myid:fe80:0:0:0:0:0:0:1%lo0:11222] - ERROR [main-SendThread(fe80:0:0:0:0:0:0:1%lo0:11222):ClientCnxnSocketNIO@287] - Unable to open socket to fe80:0:0:0:0:0:0:1%lo0/fe80:0:0:0:0:0:0:1:11222 I tried replacing that line with the following two: InetAddress.getByAddress(resolvedAddress.getAddress()); InetAddress.getByName(resolvedAddress.getHostAddress()); which gives me the following respectively: /fe80:0:0:0:0:0:0:1 /fe80:0:0:0:0:0:0:1%lo0 The first one also fails, but the second works. It looks like it doesn't work without the scope id.
          Hide
          Michael Han added a comment -

          This might related to JDK bugs for os x that literal IPv6 address does not work with Java on OS X without scope ID.
          https://bugs.openjdk.java.net/browse/JDK-8131133
          Related bugs:
          https://bugs.openjdk.java.net/browse/JDK-8132520
          https://bugs.openjdk.java.net/browse/JDK-8015415

          The attached patch seems reasonable to me, and it works for me on os x. Any reason we did not commit it? Flavio Junqueira

          Show
          Michael Han added a comment - This might related to JDK bugs for os x that literal IPv6 address does not work with Java on OS X without scope ID. https://bugs.openjdk.java.net/browse/JDK-8131133 Related bugs: https://bugs.openjdk.java.net/browse/JDK-8132520 https://bugs.openjdk.java.net/browse/JDK-8015415 The attached patch seems reasonable to me, and it works for me on os x. Any reason we did not commit it? Flavio Junqueira
          Hide
          Flavio Junqueira added a comment -

          Michael Han thanks for investigating. I didn't get a +1 here, so until then, we can't commit. Just to confirm, the path you say that works for you is the one that sets java.net.preferIPv4Stack to true, right?

          Show
          Flavio Junqueira added a comment - Michael Han thanks for investigating. I didn't get a +1 here, so until then, we can't commit. Just to confirm, the path you say that works for you is the one that sets java.net.preferIPv4Stack to true, right?
          Hide
          Michael Han added a comment -

          I see... yes the patch I validated working is the latest one uploaded on 7/8/2016 which uses IPV4 to work around the bug.

          Show
          Michael Han added a comment - I see... yes the patch I validated working is the latest one uploaded on 7/8/2016 which uses IPV4 to work around the bug.
          Hide
          Patrick Hunt added a comment -

          I'm fine with this patch, however I do have a couple concerns that would be good to address IMO:

          1) can we only override when the OS is mac, seems like we should continue to run on non-mac systems.

          2) if the property is set prior to running the setup/teardown it will end up cleared. Overriding any parameter setup prior to the test running. Rather than clearing in teardown can we reset to whatever value existed during setup?

          Show
          Patrick Hunt added a comment - I'm fine with this patch, however I do have a couple concerns that would be good to address IMO: 1) can we only override when the OS is mac, seems like we should continue to run on non-mac systems. 2) if the property is set prior to running the setup/teardown it will end up cleared. Overriding any parameter setup prior to the test running. Rather than clearing in teardown can we reset to whatever value existed during setup?
          Hide
          Camille Fournier added a comment -

          I don't absolutely love the patch fix by setting that property. Let me look at this for a minute.

          Show
          Camille Fournier added a comment - I don't absolutely love the patch fix by setting that property. Let me look at this for a minute.
          Hide
          Flavio Junqueira added a comment -

          This is also failing in jenkins, btw.

          Show
          Flavio Junqueira added a comment - This is also failing in jenkins, btw.
          Hide
          Camille Fournier added a comment -

          patch that specifies that we want the loopback address

          Show
          Camille Fournier added a comment - patch that specifies that we want the loopback address
          Hide
          Camille Fournier added a comment -

          So, the test says in comments that "if we have a loopback, and it has an address use it" but we do not request the loopback address when getting the bindAddress set. This patch does nothing but specifically request the loopback address. It passes on my machine.

          Show
          Camille Fournier added a comment - So, the test says in comments that "if we have a loopback, and it has an address use it" but we do not request the loopback address when getting the bindAddress set. This patch does nothing but specifically request the loopback address. It passes on my machine.
          Hide
          Chris Nauroth added a comment -

          That's the static InetAddress#getLoopbackAddress() method, right? If so, then we shouldn't even need to operate on an instance of InetAddress.

          Unfortunately, although this patch fixed the test on my Mac, this method was only introduced in JDK 1.7. On the 3.4 line, we document support for "JDK 6 or greater". I don't think we'd be able to commit this to branch-3.4, and the test fails for me there too.

          Should we look specifically for an IPv4 loopback address?

          Show
          Chris Nauroth added a comment - That's the static InetAddress#getLoopbackAddress() method, right? If so, then we shouldn't even need to operate on an instance of InetAddress . Unfortunately, although this patch fixed the test on my Mac, this method was only introduced in JDK 1.7. On the 3.4 line, we document support for "JDK 6 or greater". I don't think we'd be able to commit this to branch-3.4, and the test fails for me there too. Should we look specifically for an IPv4 loopback address?
          Hide
          Flavio Junqueira added a comment -

          Should we look specifically for an IPv4 loopback address?

          That's why I suggested to set java.net.preferIPv4Stack, also see the idk bugs that Michael Han pointed us to above.

          Show
          Flavio Junqueira added a comment - Should we look specifically for an IPv4 loopback address? That's why I suggested to set java.net.preferIPv4Stack , also see the idk bugs that Michael Han pointed us to above.
          Hide
          Camille Fournier added a comment -

          all JDK 1.4 and respects loopback check

          Show
          Camille Fournier added a comment - all JDK 1.4 and respects loopback check
          Hide
          Chris Nauroth added a comment -

          Patch v3 passes for me on both trunk and branch-3.4, tested on both Mac and CentOS 7.

          +1 for patch v3, pending a pre-commit run (currently blocked on some infrastructure issues). Flavio, are you OK with that too?

          I'm leaving some additional notes here too in case it's useful for anyone in the future. The latest patch got me curious about what exactly was going on here. I adapted this to a code snippet that iterates through all interfaces and addresses and prints whether they are considered loopback. Here is a Scala REPL session for that on the Mac:

          def printAddresses() = {
            val ifaces = java.net.NetworkInterface.getNetworkInterfaces
            while (ifaces.hasMoreElements) {
              val iface = ifaces.nextElement
              val addrs = iface.getInetAddresses
              while (addrs.hasMoreElements) {
                val addr = addrs.nextElement
                printf("iface=[%s], iface.isLoopback=[%s], addr=[%s], addr.isLoopbackAddress=[%s]%n",
                    iface, iface.isLoopback, addr, addr.isLoopbackAddress)
              }
            }
          }
          
          scala> printAddresses
          printAddresses
          iface=[name:awdl0 (awdl0)], iface.isLoopback=[false], addr=[/fe80:0:0:0:e836:36ff:fe8f:2795%6], addr.isLoopbackAddress=[false]
          iface=[name:vboxnet0 (vboxnet0)], iface.isLoopback=[false], addr=[/192.168.56.1], addr.isLoopbackAddress=[false]
          iface=[name:en0 (en0)], iface.isLoopback=[false], addr=[/fe80:0:0:0:3e15:c2ff:fed1:8136%4], addr.isLoopbackAddress=[false]
          iface=[name:en0 (en0)], iface.isLoopback=[false], addr=[/10.22.2.86], addr.isLoopbackAddress=[false]
          iface=[name:lo0 (lo0)], iface.isLoopback=[true], addr=[/fe80:0:0:0:0:0:0:1%1], addr.isLoopbackAddress=[false]
          iface=[name:lo0 (lo0)], iface.isLoopback=[true], addr=[/0:0:0:0:0:0:0:1], addr.isLoopbackAddress=[true]
          iface=[name:lo0 (lo0)], iface.isLoopback=[true], addr=[/127.0.0.1], addr.isLoopbackAddress=[true]
          

          Notice that for /fe80:0:0:0:0:0:0:1%1, the interface is considered loopback, but the address is not considered loopback. That seems wrong. I assume it has something to do with the JDK bugs linked above.

          This is different from my CentOS VM, where all addresses associated with the loopback interface are also considered loopback:

          scala> printAddresses
          iface=[name:enp0s8 (enp0s8)], iface.isLoopback=[false], addr=[/fe80:0:0:0:a00:27ff:fe06:287a%enp0s8], addr.isLoopbackAddress=[false]
          iface=[name:enp0s8 (enp0s8)], iface.isLoopback=[false], addr=[/192.168.56.105], addr.isLoopbackAddress=[false]
          iface=[name:enp0s3 (enp0s3)], iface.isLoopback=[false], addr=[/fe80:0:0:0:a00:27ff:fea9:db31%enp0s3], addr.isLoopbackAddress=[false]
          iface=[name:enp0s3 (enp0s3)], iface.isLoopback=[false], addr=[/10.0.2.15], addr.isLoopbackAddress=[false]
          iface=[name:lo (lo)], iface.isLoopback=[true], addr=[/0:0:0:0:0:0:0:1%lo], addr.isLoopbackAddress=[true]
          iface=[name:lo (lo)], iface.isLoopback=[true], addr=[/127.0.0.1], addr.isLoopbackAddress=[true]
          
          Show
          Chris Nauroth added a comment - Patch v3 passes for me on both trunk and branch-3.4, tested on both Mac and CentOS 7. +1 for patch v3, pending a pre-commit run (currently blocked on some infrastructure issues). Flavio, are you OK with that too? I'm leaving some additional notes here too in case it's useful for anyone in the future. The latest patch got me curious about what exactly was going on here. I adapted this to a code snippet that iterates through all interfaces and addresses and prints whether they are considered loopback. Here is a Scala REPL session for that on the Mac: def printAddresses() = { val ifaces = java.net.NetworkInterface.getNetworkInterfaces while (ifaces.hasMoreElements) { val iface = ifaces.nextElement val addrs = iface.getInetAddresses while (addrs.hasMoreElements) { val addr = addrs.nextElement printf( "iface=[%s], iface.isLoopback=[%s], addr=[%s], addr.isLoopbackAddress=[%s]%n" , iface, iface.isLoopback, addr, addr.isLoopbackAddress) } } } scala> printAddresses printAddresses iface=[name:awdl0 (awdl0)], iface.isLoopback=[ false ], addr=[/fe80:0:0:0:e836:36ff:fe8f:2795%6], addr.isLoopbackAddress=[ false ] iface=[name:vboxnet0 (vboxnet0)], iface.isLoopback=[ false ], addr=[/192.168.56.1], addr.isLoopbackAddress=[ false ] iface=[name:en0 (en0)], iface.isLoopback=[ false ], addr=[/fe80:0:0:0:3e15:c2ff:fed1:8136%4], addr.isLoopbackAddress=[ false ] iface=[name:en0 (en0)], iface.isLoopback=[ false ], addr=[/10.22.2.86], addr.isLoopbackAddress=[ false ] iface=[name:lo0 (lo0)], iface.isLoopback=[ true ], addr=[/fe80:0:0:0:0:0:0:1%1], addr.isLoopbackAddress=[ false ] iface=[name:lo0 (lo0)], iface.isLoopback=[ true ], addr=[/0:0:0:0:0:0:0:1], addr.isLoopbackAddress=[ true ] iface=[name:lo0 (lo0)], iface.isLoopback=[ true ], addr=[/127.0.0.1], addr.isLoopbackAddress=[ true ] Notice that for /fe80:0:0:0:0:0:0:1%1, the interface is considered loopback, but the address is not considered loopback. That seems wrong. I assume it has something to do with the JDK bugs linked above. This is different from my CentOS VM, where all addresses associated with the loopback interface are also considered loopback: scala> printAddresses iface=[name:enp0s8 (enp0s8)], iface.isLoopback=[ false ], addr=[/fe80:0:0:0:a00:27ff:fe06:287a%enp0s8], addr.isLoopbackAddress=[ false ] iface=[name:enp0s8 (enp0s8)], iface.isLoopback=[ false ], addr=[/192.168.56.105], addr.isLoopbackAddress=[ false ] iface=[name:enp0s3 (enp0s3)], iface.isLoopback=[ false ], addr=[/fe80:0:0:0:a00:27ff:fea9:db31%enp0s3], addr.isLoopbackAddress=[ false ] iface=[name:enp0s3 (enp0s3)], iface.isLoopback=[ false ], addr=[/10.0.2.15], addr.isLoopbackAddress=[ false ] iface=[name:lo (lo)], iface.isLoopback=[ true ], addr=[/0:0:0:0:0:0:0:1%lo], addr.isLoopbackAddress=[ true ] iface=[name:lo (lo)], iface.isLoopback=[ true ], addr=[/127.0.0.1], addr.isLoopbackAddress=[ true ]
          Hide
          Flavio Junqueira added a comment -

          Yeah, it is good for me, +1.

          Show
          Flavio Junqueira added a comment - Yeah, it is good for me, +1.
          Hide
          Michael Han added a comment -

          Pre-commit build https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3309/console failed with error message "ZOOKEEPER-ZOOKEEPER-1256 is not "Patch Available". Exiting.". Might be a transient issue, so canceling and re-trigger patch to test.

          Show
          Michael Han added a comment - Pre-commit build https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3309/console failed with error message "ZOOKEEPER- ZOOKEEPER-1256 is not "Patch Available". Exiting.". Might be a transient issue, so canceling and re-trigger patch to test.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12820539/ZOOKEEPER-1256v3.patch
          against trunk revision 1754578.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3311//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3311//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3311//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12820539/ZOOKEEPER-1256v3.patch against trunk revision 1754578. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3311//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3311//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3311//console This message is automatically generated.
          Hide
          Chris Nauroth added a comment -

          Michael Han, thank you for keeping an eye on the pre-commit run. I'll commit this later today.

          Show
          Chris Nauroth added a comment - Michael Han , thank you for keeping an eye on the pre-commit run. I'll commit this later today.
          Hide
          Patrick Hunt added a comment -

          I'm actually doing that right now.

          Show
          Patrick Hunt added a comment - I'm actually doing that right now.
          Hide
          Chris Nauroth added a comment -

          Patrick Hunt, please go ahead. Thank you!

          Show
          Chris Nauroth added a comment - Patrick Hunt , please go ahead. Thank you!
          Hide
          Patrick Hunt added a comment -

          The tests pass on my mac and on the jenkins box. Thanks Camille, et. al. ! Nice group effort.

          I've committed to 3.4.9, 3.5.3, and trunk.

          Show
          Patrick Hunt added a comment - The tests pass on my mac and on the jenkins box. Thanks Camille, et. al. ! Nice group effort. I've committed to 3.4.9, 3.5.3, and trunk.
          Hide
          Patrick Hunt added a comment -

          NP. I've been baby-sitting some of the patch jenkins jobs given the spate of jienkins environment issues we've been facing....

          Show
          Patrick Hunt added a comment - NP. I've been baby-sitting some of the patch jenkins jobs given the spate of jienkins environment issues we've been facing....
          Hide
          Hudson added a comment -

          SUCCESS: Integrated in ZooKeeper-trunk #3014 (See https://builds.apache.org/job/ZooKeeper-trunk/3014/)
          ZOOKEEPER-1256: ClientPortBindTest is failing on Mac OS X (Camille via phunt) (phunt: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1754582)

          • trunk/CHANGES.txt
          • trunk/src/java/test/org/apache/zookeeper/test/ClientPortBindTest.java
          Show
          Hudson added a comment - SUCCESS: Integrated in ZooKeeper-trunk #3014 (See https://builds.apache.org/job/ZooKeeper-trunk/3014/ ) ZOOKEEPER-1256 : ClientPortBindTest is failing on Mac OS X (Camille via phunt) (phunt: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1754582 ) trunk/CHANGES.txt trunk/src/java/test/org/apache/zookeeper/test/ClientPortBindTest.java

            People

            • Assignee:
              Flavio Junqueira
              Reporter:
              Daniel Gómez Ferro
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development