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] [Commented] (HBASE-16433) Remove AsyncRpcChannel related stuffs
Date Mon, 22 Aug 2016 07:10:21 GMT

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

Jurriaan Mous commented on HBASE-16433:

First you can not use the same CompletableFuture, the return type is different for a RpcClient
and a Table level interface. The former one will be a protobuf message and the latter one
will not. And unfortunately, CompletableFuture's chained api can not do Throwable convert
so you still need to do some nest works...

Well I currently pass the Netty future from front to back so it is possible. I do this by
passing a MessageConverter and IOExceptionConverter to the back. MessageConverter can also
be solved within CompletableFuture as you note.

And if you want to let the whole protobuf services go away, at least you also need to change
the RpcServer right? And if you really want to do this, my suggestion is to write a protoc
extension for HBase which can generate asynchronous api with a more modern style. If not,
you always need to do the method and type mapping manually and remember to change it every
time when the protobuf definition changed. This is really boring and error-prone.

Well there is not that much manual protobuf work needed since it does not depend on the contents
of the protobuf but only the MethodDescriptor. I link directly to the generated source so
they fail quickly and in one place if they change and are regenerated. It is not such big
of a hassle. I am not suggesting to change the whole server, just giving a quick path for
async clients.

And as stack said above, he is trying to make our protobuf upgradable. After he success, I
think we could try to upgrade our pb to 3.0 and try generate grpc interfaces. At that time
you could implement your RpcClient start from a more modern style asynchronous api. But now,
I still suggest we should use the old pb interfaces to implement our AsyncTable. As said above,
it has the ability to support all asynchronous operations although it is not the best solution.

A newer protobuf implementation with more modern style async api would be great. Of course
we need to move towards this future. But would a more convenient method for now give more
pleasure than pain. I think it is making stuff easier and faster for not that big of a price.

> 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

View raw message