hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10277) refactor AsyncProcess
Date Thu, 30 Jan 2014 04:04:14 GMT

    [ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886232#comment-13886232
] 

Hadoop QA commented on HBASE-10277:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12626043/HBASE-10277.03.patch
  against trunk revision .
  ATTACHMENT ID: 12626043

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 9 new or modified
tests.

    {color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 1.0 profile.

    {color:green}+1 hadoop1.1{color}.  The patch compiles against the hadoop 1.1 profile.

    {color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 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:red}-1 lineLengths{color}.  The patch introduces the following lines longer than
100:
    +          // This action failed before creating ars. Add it to retained but do not add
to submit list.
+                    " Retrying. Server is " + server.getServerName() + ", tableName=" + tableName,
t);
+                             Throwable error, long backOffTime, boolean willRetry, String
startTime){

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
                       org.apache.hadoop.hbase.io.encoding.TestChangingEncoding
                  org.apache.hadoop.hbase.rest.client.TestRemoteTable
                  org.apache.hadoop.hbase.client.TestAdmin
                  org.apache.hadoop.hbase.regionserver.TestHRegionOnCluster
                  org.apache.hadoop.hbase.rest.TestGetAndPutResource
                  org.apache.hadoop.hbase.rest.TestDeleteRow
                  org.apache.hadoop.hbase.coprocessor.TestRegionObserverInterface
                  org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster

     {color:red}-1 core zombie tests{color}.  There are 2 zombie test(s): 	at org.apache.hadoop.hbase.io.encoding.TestEncodedSeekers.testEncodedSeeker(TestEncodedSeekers.java:129)
	at org.apache.hadoop.hbase.client.TestHCM.testMulti(TestHCM.java:858)

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/8558//console

This message is automatically generated.

> refactor AsyncProcess
> ---------------------
>
>                 Key: HBASE-10277
>                 URL: https://issues.apache.org/jira/browse/HBASE-10277
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>         Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, HBASE-10277.03.patch,
HBASE-10277.patch
>
>
> AsyncProcess currently has two patterns of usage, one from HTable flush w/o callback
and with reuse, and one from HCM/HTable batch call, with callback and w/o reuse. In the former
case (but not the latter), it also does some throttling of actions on initial submit call,
limiting the number of outstanding actions per server.
> The latter case is relatively straightforward. The former appears to be error prone due
to reuse - if, as javadoc claims should be safe, multiple submit calls are performed without
waiting for the async part of the previous call to finish, fields like hasError become ambiguous
and can be used for the wrong call; callback for success/failure is called based on "original
index" of an action in submitted list, but with only one callback supplied to AP in ctor it's
not clear to which submit call the index belongs, if several are outstanding.
> I was going to add support for HBASE-10070 to AP, and found that it might be difficult
to do cleanly.
> It would be nice to normalize AP usage patterns; in particular, separate the "global"
part (load tracking) from per-submit-call part.
> Per-submit part can more conveniently track stuff like initialActions, mapping of indexes
and retry information, that is currently passed around the method calls.
> -I am not sure yet, but maybe sending of the original index to server in "ClientProtos.MultiAction"
can also be avoided.- Cannot be avoided because the API to server doesn't have one-to-one
correspondence between requests and responses in an individual call to multi (retries/rearrangement
have nothing to do with it)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message