[
https://issues.apache.org/jira/browse/HBASE-13784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14561385#comment-14561385
]
stack commented on HBASE-13784:
-------------------------------
First, sweet!
High-level, I think adding a new AsyncTable Interface is a clean way of
bringing in this new functionality. It follows nicely the Table model: get one
as you need it and then close when done (lightweight). Alternatives, ones you
have already pondered, would be adding a marker Interface on Table -- say Async
-- but then you'd have to have methods named asyncGet in your Async Interface
because you can't override if only the return is different... That'd be ugly.
Not sure I understand all that is going on but here are a few remarks on the
patch:
This would be nice:
"38 * TODO: this class is actually tied to one region, because most of the
paths make use of
39 * the regioninfo part of location when building requests. The
only reason it works for
40 * multi-region requests (e.g. batch) is that they happen to not
use the region parts.
41 * This could be done cleaner (e.g. having a generic parameter
and 2 derived classes,
42 * RegionCallable and actual RegionServerCallable with
ServerName."
...because as you note, otherwise the TableName is superfluous here:
public AbstractRegionServerCallable(Connection connection, TableName
tableName, byte[] row)
We need this method below?
protected void setLocation(final HRegionLocation location) {
It can't figure it out internally? Has to have it passed in?
The sleep, throwable, getExceptionMessageAdditionalDetail , etc., methods were
there already?
Should this be set on construction?
abstract void setClientByServiceName(ServerName serviceName) throws
IOException;
Get a new instance if you want to connect to a different service?
What is your understanding around how timeouts work now? Have you ported the
mess we have in old client where we have retries and timeouts ... with it
difficult to set an overall timeout on a connection attempt?
On your other comments:
+ I think it fine exposing netty internals; i.e. promise -- it well-known (You
going to hook up the listener on promise as over here
https://github.com/jurmous/etcd4j/blob/master/src/client/java/mousio/client/promises/ResponsePromise.java
-- smile)
+ Regards, "It is in my opinion best to remove the blocking implementation
instead of engineering fake alternatives.", and have them blocking run using
async and promise? That'd be fine.
[~sduskis] Any input on new AsyncTable Interface?
[~louiscryan] This route would jibe w/ the PoC you are doing?
> Add Async Client Table API
> --------------------------
>
> Key: HBASE-13784
> URL: https://issues.apache.org/jira/browse/HBASE-13784
> Project: HBase
> Issue Type: New Feature
> Reporter: Jurriaan Mous
> Assignee: Jurriaan Mous
> Attachments: HBASE-13784-v1.patch, HBASE-13784.patch
>
>
> With the introduction of the Async HBase RPC Client it is possible to create
> an Async Table API and more. This issue is focussed on creating a first async
> Table API so it is possible to do any non deprecated Table call in an async
> way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
