hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-6825) [WINDOWS] Java NIO socket channels does not work with Windows ipv6
Date Wed, 19 Sep 2012 00:07:08 GMT
Enis Soztutar created HBASE-6825:
------------------------------------

             Summary: [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

Mime
View raw message