[
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871439#comment-13871439
]
stack commented on HBASE-10277:
-------------------------------
Thanks for having a go at this [~sershe].
bq. The (ugly) behavior for HTable where e.g. next put will give you errors
from previous put was lovingly preserved.
Smile.
Radical!
Here are a couple of comments:
Could AsyncRequests be done as a 'Future'? Seems to have a bunch in common.
We have something called Set but it does not implement java.util.Set:
+ protected class AsyncRequestSet implements AsyncRequests {
We make an ap and a multiap each time?
+ ap = new AsyncProcess<Object>(connection, pool, configuration,
rpcCallerFactory, true);
+ multiAp = new AsyncProcess<Object>(connection, pool, configuration,
rpcCallerFactory, false);
Batch should return an array of objects?
+ Object[] results = new Object[actions.size()];
+ batch(actions, results);
+ return results;
Then you can do return batch(actions, new Object[actions.size()]);
Needs a closer review.
Whats our [~nkeywal] think?
> 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.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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
