[
https://issues.apache.org/jira/browse/HBASE-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565100#comment-13565100
]
stack commented on HBASE-7533:
------------------------------
[~devaraj]
Thanks for review.
On callid, I'll probably put it back to int in final patch just to make the
diff smaller.
On exception handling, rather than build a framework to support
exceptions-with-any-arbitrary-payload, instead, just do the handling of the one
case where we know there is payload -- RegionMovedException.
RemoteWithExtrasException is just that, the hadoop RemoteException w/ extra
info that can be exploited or not). I don't think it too bad really. We have
this one extensible ExceptionResponse that we can throw any info we need to
pass into. On client, if it supports the extra info, it can do the special
casing for whatever the new type or just shove the info into
RemoteWithExtrasException.
If you have ideas on how to make it cleaner, much appreciated.
Regards the uploaded patch, it is stale now. I want to incorporate Elliott
comments. I spent some time on it over the weekend. The upfront total length
of the request and response that Elliott suggested we punt is unavoidable it
seems, unless we rewrite the server-side. The server has a loop which reads
ints and dependent on int content and its current processing state, pulls in
the preamble, reads the connection header, or reads in the WHOLE request. The
server is about bytebuffers gotten off the server socket channel and though it
is technically async, the way the server is written, it expects to be able to
pull all the bytes that make up the request in one giant sucking read. Though
it gives the impression that you could 'park' the read and continue it later if
all bytes are net yet present on the wire, that facility is not hooked up.
It would be sweet being able to park the read or just read the header and if
not high priority, come back for the request part latter but I'm thinking that
is v2 of the rpc protocol when we go full async on the server side.
Regards hbase-5945, pbs are worth study. Unless you pass an explicit byte
array size for the Message, pb will under the wrappers instantiate a
Coded*Stream whose construction will allocate a 4k buffer which we do not want.
I was messing trying to figure the marshalling/unmarshalling path that does
least copying and allocations and looking at pb 2.5.0, as yet unreleased, which
claims its new parse method 25% faster...
I"ll be back.
> Write an RPC Specification for 0.96
> -----------------------------------
>
> Key: HBASE-7533
> URL: https://issues.apache.org/jira/browse/HBASE-7533
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: stack
> Fix For: 0.96.0
>
> Attachments: 7533_proto_sketch.txt, rpc_spec3.txt, rpc_spec.txt
>
>
> RPC format is changing for 0.96 to accomodate our protobufing all around.
> Here is a first cut. Please shred:
> https://docs.google.com/document/d/1-1RJMLXzYldmHgKP7M7ynK6euRpucD03fZ603DlZfGI/edit
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
