[
https://issues.apache.org/jira/browse/HBASE-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725190#comment-13725190
]
Hadoop QA commented on HBASE-7634:
----------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12595161/HBASE-7634.v6.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 4 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{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:green}+1 findbugs{color}. The patch does not introduce any 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:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6543//console
This message is automatically generated.
> Replication handling of changes to peer clusters is inefficient
> ---------------------------------------------------------------
>
> Key: HBASE-7634
> URL: https://issues.apache.org/jira/browse/HBASE-7634
> Project: HBase
> Issue Type: Bug
> Components: Replication
> Affects Versions: 0.95.2
> Reporter: Gabriel Reid
> Attachments: HBASE-7634.patch, HBASE-7634.v2.patch,
> HBASE-7634.v3.patch, HBASE-7634.v4.patch, HBASE-7634.v5.patch,
> HBASE-7634.v6.patch
>
>
> The current handling of changes to the region servers in a replication peer
> cluster is currently quite inefficient. The list of region servers that are
> being replicated to is only updated if there are a large number of issues
> encountered while replicating.
> This can cause it to take quite a while to recognize that a number of the
> regionserver in a peer cluster are no longer available. A potentially bigger
> problem is that if a replication peer cluster is started with a small number
> of regionservers, and then more region servers are added after replication
> has started, the additional region servers will never be used for replication
> (unless there are failures on the in-use regionservers).
> Part of the current issue is that the retry code in
> ReplicationSource#shipEdits checks a randomly-chosen replication peer
> regionserver (in ReplicationSource#isSlaveDown) to see if it is up after a
> replication write has failed on a different randonly-chosen replication peer.
> If the peer is seen as not down, another randomly-chosen peer is used for
> writing.
> A second part of the issue is that changes to the list of region servers in a
> peer cluster are not detected at all, and are only picked up if a certain
> number of failures have occurred when trying to ship edits.
--
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
