hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Sigoure (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3581) hbase rpc should send size of response
Date Thu, 03 Mar 2011 22:26:37 GMT

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

Benoit Sigoure commented on HBASE-3581:
---------------------------------------

-1: Can we *please* find a way of making this change such that clients can still support the
"old" protocol and the new one at the same time?

For instance, after sending the "hello" header ("hrpc3" + creds) maybe the server could reply
(right now it doesn't) and say "hey, here's my version info".  Because you can't use the {{getProtocolVersion}}
RPC to find about this incompatibility.

Other possibility: swap the errorFlag and the size, and use an extra bit in the error flag,
not to indicate an error but to indicate that the size follows.  If we do this, we should
refer to "errorFlag" as just "flag" since it's not going to be only about errors anymore.

> hbase rpc should send size of response
> --------------------------------------
>
>                 Key: HBASE-3581
>                 URL: https://issues.apache.org/jira/browse/HBASE-3581
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: ryan rawson
>            Assignee: ryan rawson
>             Fix For: 0.92.0
>
>         Attachments: HBASE-rpc-response.txt
>
>
> The RPC reply from Server->Client does not include the size of the payload, it is
framed like so:
> <i32> callId
> <byte> errorFlag
> <byte[]> data
> The data segment would contain enough info about how big the response is so that it could
be decoded by a writable reader.
> This makes it difficult to write buffering clients, who might read the entire 'data'
then pass it to a decoder. While less memory efficient, if you want to easily write block
read clients (eg: nio) it would be necessary to send the size along so that the client could
snarf into a local buf.
> The new proposal is:
> <i32> callId
> <i32> size
> <byte> errorFlag
> <byte[]> data
> the size being sizeof(data) + sizeof(errorFlag).

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message