hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jurriaan Mous (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-16433) Remove AsyncRpcChannel related stuffs
Date Wed, 17 Aug 2016 20:28:20 GMT

    [ 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)

Mime
View raw message