[
https://issues.apache.org/jira/browse/HBASE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-6825:
---------------------------------
Attachment: hbase-6825_v3-trunk.patch
hbase-6825_v3-0.94.patch
Attaching v3 patches
> [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.94.3, 0.96.0
> Environment: JDK6 on windows for ipv6.
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Attachments: hbase-6825_v3-0.94.patch, hbase-6825_v3-trunk.patch
>
>
> 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
