hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17345) Implement batch
Date Thu, 22 Dec 2016 02:01:02 GMT

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

We take startLogErrorsCnt as a param but ignore it?
It is just for debugging... Will do some cleanup in the next patch.

You make a new Action from passed-in Action because you don't want to modify passed-in params?
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.

super nit: you can presize the following 148	this.action2Errors = new IdentityHashMap<>();
If there is no error then the map will remain empty after we finish. I think this is the common

This is just to log? 208	long currentTime = System.currentTimeMillis(); i.e. all timing is
with nanos but millis is just for logging?
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)

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?
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.

Why we have AsyncTable and AsyncTableBase again? Do we have to have the two Interfaces?
There were introduced when implementing scan. See the discussion in HBASE-16984. We can discuss
later whether we can just have one AsyncTable interface.

Do you have to rename TestAsyncGetMultiThread ? And/or TestAsyncTableMultiGet?
No, it is get, not multi get... I will rename TestAsyncTableMultiGet and add other batch tests
to it.


> 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

View raw message