You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jurriaan Mous (JIRA)" <ji...@apache.org> on 2016/08/17 20:28:20 UTC

[jira] [Comment Edited] (HBASE-16433) Remove AsyncRpcChannel related stuffs

    [ https://issues.apache.org/jira/browse/HBASE-16433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425297#comment-15425297 ] 

Jurriaan Mous edited comment on HBASE-16433 at 8/17/16 8:27 PM:
----------------------------------------------------------------

I implemented two ways to do the Async Calls: createProtobufRpcChannel which handles everything the protobuf way with RpcChannel and createRpcChannel which exposes a bit of the Netty internals. I wanted to have this second route so the Table impl doesn't need to do everything with wrapping in cumbersome RpcController and RpcCallback which are not developer friendly for async communication. You can see some hacking around the RpcChannel barrier with the PayloadCarryingRpcController to just pass on variables to the Rpc layers. I wanted something simpler for the Async client with a more direct connection to what is happening in the Rpc layer. 

I am agreeing that leaking Netty is not the way forward and I want to replace that with java native CompletableFuture which is Java 8 only. So we can pass that on from the lower RPC layers without any hacking around the Protobuf RPC layers. But it is being hold up by HBASE-15624 and that was hold back by the just fixed HBASE-15882

So my vote would be to leave the more direct way of communicating with the RPC layers with AsyncRpcChannel in but to base it on CompletableFuture as is in patch v1 in HBASE-15978. Then it would also be easier to land the AsyncTableImpl so it is more visible why the AsyncRpcChannel is there.


was (Author: jurmous):
I implemented two ways to do the Async Calls: createProtobufRpcChannel which handles everything the protobuf way with RpcChannel and createRpcChannel which exposes a bit of the Netty internals. I wanted to have this second route so the Table impl doesn't need to do everything with wrapping in cumbersome RpcController and RpcCallback which are not developer friendly for a complete async interfaces. You see now hacking around that barrier with PayloadCarryingRpcController to just pass on variables to the Rpc layers. I wanted something simpler for the Async client with a more direct connection to what is happening in the Rpc layer. 

I am agreeing that leaking Netty is not the way forward and I want to replace that with java native CompletableFuture which is Java 8 only. So we can pass that on from the lower RPC layers without any hacking around the Protobuf RPC layers. But it is being hold up by HBASE-15624 and that was hold back by the just fixed HBASE-15882

So my vote would be to leave the more direct way of communicating with the RPC layers with AsyncRpcChannel in but to base it on CompletableFuture as is in patch v1 in HBASE-15978. Then it would also be easier to land the AsyncTableImpl so it is more visible why the AsyncRpcChannel is there.

> Remove AsyncRpcChannel related stuffs
> -------------------------------------
>
>                 Key: HBASE-16433
>                 URL: https://issues.apache.org/jira/browse/HBASE-16433
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 2.0.0
>            Reporter: Duo Zhang
>            Assignee: Duo Zhang
>             Fix For: 2.0.0
>
>         Attachments: HBASE-16433.patch
>
>
> AsyncRpcChannel can not be used by protobuf stub. We should implement the async logic along with the RpcChannel interface of protobuf.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)