[
https://issues.apache.org/jira/browse/HBASE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13560385#comment-13560385
]
Hadoop QA commented on HBASE-6825:
----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12551445/hbase-6825_v3-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 3 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestLocalHBaseCluster
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4141//console
This message is automatically generated.
> [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
