[
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868855#comment-13868855
]
Andrew Purtell commented on HBASE-10277:
----------------------------------------
bq. The (ugly) behavior for HTable where e.g. next put will give you errors
from previous put was lovingly preserved.
To my mind this is a serious problem because the application is getting
incorrect feedback on what operation actually failed.
> 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)
