Hadoop QA
added a comment - 27/Oct/11 08:50 -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.

Patrick Hunt
added a comment - 27/Oct/11 17:37 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?

Daniel Gómez Ferro
added a comment - 27/Oct/11 18:11 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

Daniel Gómez Ferro
added a comment - 27/Oct/11 18:17 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?

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!

Patrick Hunt
added a comment - 27/Oct/11 19:18 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!