hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Async RpcClient
Date Thu, 18 Dec 2014 21:22:52 GMT
On Wed, Dec 17, 2014 at 9:44 AM, Jurriaan Mous <jurmous@jurmo.us> wrote:
> Hi,
> I have been working on a Netty 4 based async HBase client to fit better
> within the event driven server I have been developing. -
> https://github.com/jurmous/async-hbase-client/tree/HBase-0.99 <
> https://github.com/jurmous/async-hbase-client/tree/HBase-0.99>
> Recently I have been submitting some patches to make it easier to switch
> out the RpcClient of HBase. This to enable HBase to use the client itself
> in all communication. I wanted to do this to use the tests on HBase to
> check if the client was solid on all edge cases but also to enable HBase to
> possibly migrate to an async client. These were committed on master and
> branch-1
> https://issues.apache.org/jira/browse/HBASE-12597 <
> https://issues.apache.org/jira/browse/HBASE-12597>
> https://issues.apache.org/jira/browse/HBASE-12684 <
> https://issues.apache.org/jira/browse/HBASE-12684>
> Now I am at the next step where I want to contribute back the
> AsyncRpcClient itself.

> I have opened this issue to add AsyncRpcClient:
> https://issues.apache.org/jira/browse/HBASE-12684 <
> https://issues.apache.org/jira/browse/HBASE-12684>
> In the current patch the new async client is the default.
> 3 questions:
> Can anyone with a proper Kerberos setup test if the async client works?
> SASL Digest auth works but I haven’t tested Kerberos yet.
> Can anyone with know-how on benchmarking test what the performance of this
> client is compared to the current client? The performance should of course
> be great in all relevant metrics will it ever be the main client.
I can have a go at the above Jurriaan, maybe next week?

> What will we do with the old RpcClient if the async RpcClient is
> introduced? It would be great to remove it so hbase can internally base
> anything async (like AsyncProcess) on the async RPC client and this would
> not be possible with an also supported sync RPC client. A possible route is
> to make AsyncRpcClient an option on 1.x and a default on 2.0 branch where
> we remove the old client.
Option in 1.1 and default in 2.0 would be the way to go after we get some
signal it is an improvement.

> When the new AsyncRpcClient will be the default it is possible to
> introduce callback variants of the Table, Scanner and Admin methods and
> possibly deprecate batch and other AsyncProcess based calls to replace it
> with a more flexible batch callback implementation.
 Excellent.  These additions would complement/decorate the new 1.0


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message