[
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:
---------------------------------------
{quote}
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...
{quote}
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.
{quote}
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.
{quote}
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.
{quote}
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.
{quote}
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
(v6.3.4#6332)
