[
https://issues.apache.org/jira/browse/HBASE-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15768749#comment-15768749
]
Duo Zhang commented on HBASE-17345:
-----------------------------------
{quote}
We take startLogErrorsCnt as a param but ignore it?
{quote}
It is just for debugging... Will do some cleanup in the next patch.
{quote}
You make a new Action from passed-in Action because you don't want to modify
passed-in params?
{quote}
The action passed in is a Row, i.e., Get, Put, Delete etc. And we will use it
to construct an Action Object. It records the originalIndex of the action and
also carries the nonce.
{quote}
super nit: you can presize the following 148 this.action2Errors = new
IdentityHashMap<>();
{quote}
If there is no error then the map will remain empty after we finish. I think
this is the common case?
{quote}
This is just to log? 208 long currentTime = System.currentTimeMillis();
i.e. all timing is with nanos but millis is just for logging?
{quote}
Just follow the old log pattern. It is use to construct the error message of
RetriesExhaustedException. And I think it is reasonable as it is more friendly
for the user to get a date(think of PrintGCTimeStamps VS. PrintGCDateStamps)
{quote}
What do you see AsyncBatchRpcRetryingCaller replacing in our current stack? It
seems to do AP and a bunch of our Callable infra. Should
AsyncBatchRpcRetryingCaller implement Callable? Or what you thinking?
{quote}
I plan to use it to replace AsyncProcess. And there is no callable in the
current client implementation stack(or maybe some simple ones, see
AsyncSingleRequestRpcRetryingCaller). With this patch, I think most retrying
callers for async table are in place. The exceptions are read replica
support(HBASE-17356), and endpoint support(HBASE-17346). And still need to
improve the scan implementation(mvcc, inclusive/exclusive of start row and end
row, etc.). But I think it is time to think about building the old blocking API
on top of the new async API and get rid of the old code.
{quote}
Why we have AsyncTable and AsyncTableBase again? Do we have to have the two
Interfaces?
{quote}
There were introduced when implementing scan. See the discussion in
HBASE-16984. We can discuss later whether we can just have one AsyncTable
interface.
{quote}
Do you have to rename TestAsyncGetMultiThread ? And/or TestAsyncTableMultiGet?
{quote}
No, it is get, not multi get... I will rename TestAsyncTableMultiGet and add
other batch tests to it.
Thanks.
> Implement batch
> ---------------
>
> Key: HBASE-17345
> URL: https://issues.apache.org/jira/browse/HBASE-17345
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client
> Affects Versions: 2.0.0
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17345.patch
>
>
> Add the support for general batch based on the code introduced in HBASE-17142.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
