[
https://issues.apache.org/jira/browse/HBASE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993279#comment-12993279
]
Jonathan Gray commented on HBASE-3523:
--------------------------------------
A binary, language agnostic underlying RPC and wire protocol. Async, as an
option, would be nice as well.
I'd like more visibility and control into what is happening underneath with
respect to connections to RegionServers and such. I don't like all the
staticness and voodoo magic, at least not as the only option. The usage of
like a hash of Configuration has always been weird to me.
A better API for how errors are returned, for example, I can never understand
how the MultiAction stuff without digging into code.
+1 to your suggestions. We can already do stuff off the back of ZK for region
movement if we wanted, but the opportunity for little hints in RPCs would be
neat as well.
Thanks for filing this stack.
> Rewrite our client
> ------------------
>
> Key: HBASE-3523
> URL: https://issues.apache.org/jira/browse/HBASE-3523
> Project: HBase
> Issue Type: Brainstorming
> Reporter: stack
>
> Is it just me or do others sense that there is pressure building to redo the
> client? If just me, ignore the below... I'll just keep notes in here.
> Otherwise, what would the requirements for a client rewrite look like?
> + Let out InterruptedException
> + Enveloping of messages or space for metadata that can be passed by client
> to server and by server to client; e.g. the region a.b.c moved to server
> x.y.z. or scanner is finished or timeout
> + A different RPC? One with tighter serialization.
> + More sane timeout/retry policy.
> Does it have to support async communication? Do callbacks?
> What else?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
