[
https://issues.apache.org/jira/browse/HBASE-16433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427744#comment-15427744
]
Jurriaan Mous commented on HBASE-16433:
---------------------------------------
With the protobuf service abstraction we are doing more object creation each
time we do a call. We want in our async calls to expose a CompletableFuture,
for which the request needs to be converted to a PayloadCarryingRpcController
and a callback, which needs to be converted to a kind of Promise within the
Netty RPC layer. With the other route without Protobuf services we can pass a
CompletableFuture from back to front without passing any implementation details
about Netty (or possible future grpc implementation).
The Descriptors.MethodDescriptor in the AsyncRpcChannel is indeed not nice but
we can abstract that away with an Enum/ a class which contains the generated
MDs.
I would much rather prefer that we abstract the whole protobuf services away
and make all our client/table implementations immune to change to FE grpc than
to leak protobuf services everywhere. A simple method that inputs anything our
client needs and outputs a CompletableFuture seems to be much more change
proof. Then we can slowly phase out anything Protobuf service related and we
have more performant Clients because there is less conversion/object creation
tax.
> 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)
