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

{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)

Mime
View raw message