hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-10277) refactor AsyncProcess
Date Sat, 04 Jan 2014 00:36:50 GMT
Sergey Shelukhin created HBASE-10277:

             Summary: 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

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.

This message was sent by Atlassian JIRA

View raw message