hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15921) Add first AsyncTable impl and create TableImpl based on it
Date Wed, 12 Oct 2016 19:46:20 GMT

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

stack commented on HBASE-15921:

In rb we discuss curator in client. Our RecoverableZK does the stamping of a version into
the data so we recognize missed updates, a facility that curator does not have (why don't
we rely on the znode version number for figuring if we missed an edit -- because it is out
of band rather than inline as RecoverableZK does it?).

Up in rb too, we talked about difference between how we use zk in client where we have a watcher
to notify us on changes compared to asynchbase which just opens connection to zk, reads what
it needs, then closes it... only reopening if it needs to because of some change in circumstance.
This to me seems simpliest implementation we could have in client for zk use  but [~Apache9]
you say registering for watchers makes our code cleaner?

> 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

View raw message