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
(v6.1.5#6160)
