[
https://issues.apache.org/jira/browse/HBASE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458315#comment-13458315
]
Enis Soztutar commented on HBASE-6825:
--------------------------------------
The ipv6 test attached at http://bugs.sun.com/view_bug.do?bug_id=6230761 works
with jdk1.7.0_6, but not with jdk1.6.0_33 (Windows Server 2008 R2).
{code}
PS C:\Program Files\Java\jdk1.6.0_33\bin> .\java.exe -cp '.\target\classes' ipv6
==> 1
==> 2
java.net.SocketException: Address family not supported by protocol family: bind
at sun.nio.ch.Net.bind(Native Method)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
at ipv6.main(ipv6.java:30)
{code}
{code}
PS C:\Program Files\Java\jdk1.7.0_06\bin> .\java.exe -cp '.\target\classes' ipv6
==> 1
==> 2
==> 3
{code}
There are 3 possible workarounds:
1.) set socket address preference to IPV4 –
{code}
-Djava.net.preferIPv4Stack=true
{code}
2.) use "classic" sockets instead of NIO:
{code}
ServerSocket s = new ServerSocket();
s.bind(new InetSocketAddress(InetAddress.getByName("::"), 0));
{code}
3) set
{code}
reg add
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters\ /v
DisabledComponents /t REG_BINARY /d 20
{code}
setting it either 0x20 of 0xffffffff.
http://support.microsoft.com/kb/929852
http://serverfault.com/questions/218745/disable-ipv6-on-loopback-address-localhost-computer-name
This will either disable ipv6, or cause preference of v4 over v6 on the node.
However, It seems that 1) is the best approach right now. Note that we have to
set -Djava.net.preferIPv4Stack=true at maven (for tests), hbase-env (for
deployment), and eclipse (if used for development). I'll provide a patch.
Following shows that preferIPv4 works as intended:
{code}
public class TestPreferIpv4 {
@Test
public void testPreferIpv4() throws Exception {
System.setProperty("java.net.preferIPv4Stack" , "true");
InetAddress[] addrs = InetAddress.getAllByName("localhost");
for (InetAddress addr : addrs) {
System.out.println(addr);
}
}
public static void main(String[] args) throws Exception {
new TestPreferIpv4().testPreferIpv4();
}
}
{code}
> [WINDOWS] Java NIO socket channels does not work with Windows ipv6
> ------------------------------------------------------------------
>
> Key: HBASE-6825
> URL: https://issues.apache.org/jira/browse/HBASE-6825
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 0.96.0, 0.94.3
> Environment: JDK6 on windows for ipv6.
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
>
> While running the test TestAdmin.testCheckHBaseAvailableClosesConnection(), I
> noticed that it takes very long, since it sleeps for 2sec * 500, because of
> zookeeper retries.
> The root cause of the problem is that ZK uses Java NIO to create
> ServerSorcket's from ServerSocketChannels. Under windows, the ipv4 and ipv6
> is implemented independently, and Java seems that it cannot reuse the same
> socket channel for both ipv4 and ipv6 sockets. We are getting
> "java.net.SocketException: Address family not supported by protocol
> family" exceptions. When, ZK client resolves "localhost", it gets both v4
> 127.0.0.1 and v6 ::1 address, but the socket channel cannot bind to both v4
> and v6.
> The problem is reported as:
> http://bugs.sun.com/view_bug.do?bug_id=6230761
> http://stackoverflow.com/questions/1357091/binding-an-ipv6-server-socket-on-windows
> Although the JDK bug is reported as resolved, I have tested with jdk1.6.0_33
> without any success. Although JDK7 seems to have fixed this problem. In ZK,
> we can replace the ClientCnxnSocket implementation from ClientCnxnSocketNIO
> to a non-NIO one, but I am not sure that would be the way to go.
> Disabling ipv6 resolution of "localhost" is one other approach. I'll test it
> to see whether it will be any good.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
