[
https://issues.apache.org/jira/browse/HBASE-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729844#comment-13729844
]
Hadoop QA commented on HBASE-9095:
----------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12596163/9095-2.txt
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 6 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/6605//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6605//console
This message is automatically generated.
> AssignmentManager's handleRegion should respect the single threaded nature of
> the processing
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-9095
> URL: https://issues.apache.org/jira/browse/HBASE-9095
> Project: HBase
> Issue Type: Bug
> Components: Region Assignment
> Reporter: Devaraj Das
> Assignee: Devaraj Das
> Fix For: 0.95.2
>
> Attachments: 9095-1 (1).txt, 9095-1.txt, 9095-1.txt, 9095-1.txt,
> 9095-2.txt
>
>
> While debugging a case where a region was getting opened on a RegionServer
> and then closed soon after (and then never re-opened anywhere thereafter), it
> seemed like the processing in handleRegion to do with deletion of ZK nodes
> should be non-asynchronous. This achieves two things:
> 1. The synchronous deletion prevents more than one processing on the same
> event data twice. Assuming that we do get more than one notification (on
> let's say, region OPENED event), the subsequent processing(s) in handleRegion
> for the same znode would end up with a zookeeper node not found exception.
> The return value of the data read would be null and that's already handled.
> If it is asynchronous, it leads to issues like - master opens a region on a
> certain RegionServer and soon after it sends that RegionServer a close for
> the same region, and then the znode is deleted.
> 2. The deletion is currently handled in an executor service. This is
> problematic since by design the events for a given region should be processed
> in order. By delegating a part of the processing to executor service we are
> somewhat violating this contract since there is no guarantee of the ordering
> in the executor service executions...
> Thanks to [~jeffreyz] and [~enis] for the discussions on this issue.
--
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
