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-13784) Add Async Client Table API
Date Wed, 27 May 2015 18:06:18 GMT

    [ 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
39	 *       the regioninfo part of location when building requests. The only reason it works
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

View raw message