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

stack commented on HBASE-12597:
-------------------------------

bq. And I would like to switch out the RpcClient in whatever the default 
implementation is so I don't need to reimplement everything in a new Connection 
implementation. 

I was just trying to warn you off the implementation to instead work against 
the Connection (rather than HCI) if possible.  The new Interfaces are kinda 
sweet. Would be grand if your new rpc Interface could be in the same style.

bq. I have been working of the 0.98 branch with my project since I currently 
use that within my project. 

Fair enough. Make it work in your context first.

bq. I have studied what has changed in master-1 and it would not be difficult 
to incorporate the changes. 

Sweet.

bq. While it looks like it implemented to be as fast as possible it missed out 
on a few features that I was using. 

That is a good characterization I would say.

bq. And I used the Hbase implementation as the basis for connection pooling and 
more so I wouldn't reinvent the wheel.

Can you say more on the above?  Why would you use hbase implementation 
connection pooling and not Netty's (I'm not sure -- I'm guessing it can do this)

I'm am glad there was a mapping from our configs to those needed by netty. Good.

Do you have a proposal for rpcclient interface?

There is our use of the protobuf Service Interfaces taking rpc controllers etc. 
 We just took it on because it was there and the pb code generation did all the 
stubbing for us.  Just saying we are amenable to change long as the basic 
protocol stays the same, for now.

bq. I already reimplemented the SASL handling to be a channel handler and you 
need to add the compression to be after (or possibly before) the SASL handler 
for it to work correctly. 

That'd be pretty great. Thinking on it, I suppose it should be ok doing it as 
netty channel. You just have to have our idiosyncratic header stuff up  front 
on the connection which I believe netty will let you just insert. Thats great.

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

Reply via email to