[
https://issues.apache.org/jira/browse/HBASE-15921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308261#comment-15308261
]
stack commented on HBASE-15921:
-------------------------------
Some notes after a quick scan of the patch (you might want to make use of the
new ./dev-support/submit-patch.py util going forward... does put to issue and
to rb at same time).
This has to be this way? (Lots of abstract classes...)
public abstract class AsyncRegionServerCallable<T> extends
AbstractRegionServerCallable<T>
It probably has to be given you are coming into a convoluted hierarchy that has
accreted over a long period of time. Was just wondering if could have a
shallower hierarchy. No issue if can't be done easily... or has to wait till
later after you've gotten your async client in.
Or, you just moved this existing class out to its own file?
AsyncTable returns Future only? Not CompletableFuture? Consumers won't be able
to consume AsyncTable in an event-driven way? We need a callback?
Why we let out EventExecutor? Especially given it a netty class. Can we contain
the fact that the implementation is netty-based?
In successful future it has a class comment "25 * A Failed Response future"
The replacement of HTable by TableImpl comes later?
Any chance of a note on how the PromiseKeepers work?
[~Apache9] and [~mbertozzi], have a look here lads... you might have a comment
or so.
> 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
> Reporter: Jurriaan Mous
> Assignee: Jurriaan Mous
> Attachments: 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)
