[
https://issues.apache.org/jira/browse/HBASE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230238#comment-14230238
]
stack commented on HBASE-12597:
-------------------------------
[~jurmous] Just in case you've not seen this before,
http://hbase.apache.org/book.html#hbase.rpc
I just pushed a new snapshot for you so you have more current state of code.
Its 0.99.2-SNAPSHOT.
Regards branch-1, would be good to get your Interface in even if your netty
client is not done yet...
Yes, keying connections by ConnectionId is the way to go with this as the key
client apps use to find existing connections if they exist.
bq. And the client uses the map to give users an existing or a new connection.
Yes. Be careful here though. You should be ok but we just made a change where
the management of connections was done under the covers for applications such
that internally we did connection setup and then did refcounting so if multiple
client apps, they could share underlying connections. We've moved away from
doing this internally forcing client apps to do this going forward (In past you
got a HTable instance, not you first get a Connection and then Table
instance... With the former the Connection setup and management was done
internally... with the latter style, it is up to the app to manage the
Connection). Just FYI.
bq. Although I could see that it could be made more optimal since like the
Hbase implementation I also needed to create a new async
PayloadCarryingRpcController to pass information around the limiting interface.
Yeah. Above is ugly but as you say, we can move off the pb generated stubs at
some other time.
Good stuff
> Add RpcClient interface and enable changing of RpcClient implementation
> -----------------------------------------------------------------------
>
> Key: HBASE-12597
> URL: https://issues.apache.org/jira/browse/HBASE-12597
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Reporter: Jurriaan Mous
> Attachments: HBASE-12597.patch
>
>
> Currently HConnectionImplementation works with the included RpcClient which
> is a direct implementation and not defined by an interface.
> It would be great to be able to swap out the default RpcClient with another
> implementation which can also be controlled by the default
> HConnectionImplementation.
> Suggested changes:
> - Create a RpcClient interface which defines all the ways
> HConnectionImplementation interacts with an RPC client. Like getting a
> blocking protobuf service interface or closing the client.
> - Define which RpcClient implementation to construct by setting a
> configuration variable which defaults to the current RpcClient.
> - Possibly create an abstract RpcClient class to only load all the basic Rpc
> layer configurations to be used in an implementation.
> Why? It enables experimentation with RpcClients which could enable new
> features or could be more performant than the included client.
> I created a new RpcClient implementation based on Netty which can also be
> called asynchronously. It would be great to also be able to use this
> RpcClient in all the default ways and tests to see if there are any issues
> with it.
> https://github.com/jurmous/async-hbase-client/
> https://github.com/jurmous/async-hbase-client/blob/master/src/main/java/org/apache/hadoop/hbase/ipc/AsyncRpcClient.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
