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

Reply via email to