hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nkeywal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5924) In the client code, don't wait for all the requests to be executed before resubmitting a request in error.
Date Fri, 08 Jun 2012 09:59:23 GMT

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

nkeywal commented on HBASE-5924:
--------------------------------

bq. With RSTracker gone, the following flag is no longer checked:
Aggreed, but this unit test is supposed to test if the region server aborted when the coprocessor
bugged, not if the regionserver znode is deleted on regionserver abort. I propose to check
if there is an existing test on this in the tests suite and if not add it in the regionserver
test package. I will comment in this jira if there is already a test, create a new one if
I need to extend an existing test case.

bq. table.close();
Yeah, I checked and it's still works, with or without the close.

                
> In the client code, don't wait for all the requests to be executed before resubmitting
a request in error.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-5924
>                 URL: https://issues.apache.org/jira/browse/HBASE-5924
>             Project: HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.96.0
>            Reporter: nkeywal
>            Assignee: nkeywal
>             Fix For: 0.96.0
>
>         Attachments: 5924.v11.patch, 5924.v14.patch, 5924.v5.patch, 5924.v9.patch
>
>
> The client (in the function HConnectionManager#processBatchCallback) works in two steps:
>  - make the requests
>  - collect the failures and successes and prepare for retry
> It means that when there is an immediate error (region moved, split, dead server, ...)
we still wait for all the initial requests to be executed before submitting again the failed
request. If we have a scenario with all the requests taking 5 seconds we have a final execution
time of: 5 (initial requests) + 1 (wait time) + 5 (final request) = 11s.
> We could improve this by analyzing immediately the results. This would lead us, for the
scenario mentioned above, to 6 seconds. 
> So we could have a performance improvement of nearly 50% in many cases, and much more
than 50% if the request execution time is different.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message