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-15921) Add first AsyncTable impl and create TableImpl based on it
Date Wed, 12 Oct 2016 05:35:20 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15567669#comment-15567669
] 

Duo Zhang commented on HBASE-15921:
-----------------------------------

[~enis] Any other concerns?

For curator, I think it will simplify our client code a lot as we do not need to deal with
retry and recovery, and the API is more friendly. And the client only needs to access a small
set of data on zk, you can see the ClusterRegistry interface in patch v6, that's all. So I
think implement the client logic separately is good for both the client and server implementations
as the zk implementation does not need to deal with client any more.

And I know that sometimes we need the client API to do something at server side, but I think
this is another story. We can discuss it later. And the client side zk related implementation
is not very complicated so if we decide to remove the dependency of curator it is OK to reimplement
it at that time.

Thanks.

> Add first AsyncTable impl and create TableImpl based on it
> ----------------------------------------------------------
>
>                 Key: HBASE-15921
>                 URL: https://issues.apache.org/jira/browse/HBASE-15921
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 2.0.0
>            Reporter: Jurriaan Mous
>            Assignee: Duo Zhang
>             Fix For: 2.0.0
>
>         Attachments: HBASE-15921-v2.patch, HBASE-15921-v3.patch, HBASE-15921-v4.patch,
HBASE-15921-v5.patch, HBASE-15921-v6.patch, HBASE-15921-v7.patch, HBASE-15921-v8.patch, HBASE-15921.demo.patch,
HBASE-15921.patch, HBASE-15921.v1.patch
>
>
> First we create an AsyncTable interface with implementation without the Scan functionality.
Those will land in a separate patch since they need a refactor of existing scans.
> Also added is a new TableImpl to replace HTable. It uses the AsyncTableImpl internally
and should be a bit faster because it does jump through less hoops to do ProtoBuf transportation.
This way we can run all existing tests on the AsyncTableImpl to guarantee its quality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message