[
https://issues.apache.org/jira/browse/HADOOP-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554818#comment-13554818
]
Binglin Chang commented on HADOOP-8990:
---------------------------------------
Thanks for all this, Sanjay. Let me summarize it to see if I fully understand
it?
The final wire format would be(I assume prefix is unified to 4 byte integer):
request:
|4byte total length|4byte header len|header|4byte request len|request|
response:
|4byte total length|4byte header len|header(with error string)|4byte response
len(optional if error)|response(optional if error)|
Still I prefer the most simple way.
request:
|4byte length|request(with request no type bytes)|
response:
|4byte length|response(with optional response no type bytes and optional error)|
But if you choose the above solution, I'm also OK.
What's the detail of avoiding buffer copy? I post in another thread that
writedelimited to can't avoid buffer copy, and codedinputstream create a buffer
to serialized, so unless we use one codeinputstream throughout code, it maybe
be difficult otherwise.
> Some minor issus in protobuf based ipc
> --------------------------------------
>
> Key: HADOOP-8990
> URL: https://issues.apache.org/jira/browse/HADOOP-8990
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Binglin Chang
> Priority: Minor
>
> 1. proto file naming
> RpcPayloadHeader.proto include not only RpcPayLoadHeaderProto, but also
> RpcResponseHeaderProto, which is irrelevant to the file name.
> hadoop_rpc.proto only include HadoopRpcRequestProto, and the filename
> "hadoop_rpc" is strange comparing to other .proto file names.
> How about merge those two file into HadoopRpc.proto?
> 2. proto class naming
> In rpc request RpcPayloadHeaderProto includes callId, but in rpc response
> callId is included in RpcResponseHeaderProto, and there is also
> HadoopRpcRequestProto, this is just too confusing.
> 3. The rpc system is not fully protobuf based, there are still some Writables:
> RpcRequestWritable and RpcResponseWritable.
> rpc response exception name and stack trace string.
> And RpcRequestWritable uses protobuf style varint32 prefix, but
> RpcResponseWritable uses int32 prefix, why this inconsistency?
> Currently rpc request is splitted into length, PayLoadHeader and PayLoad, and
> response into RpcResponseHeader, response and error message.
> I think wrap request and response into single RequstProto and ResponseProto
> is better, cause this gives a formal complete wire format definition,
> or developer need to look into the source code and hard coding the
> communication format.
> These issues above make it very confusing and hard for developers to use
> these rpc interfaces.
> Some of these issues can be solved without breaking compatibility, but some
> can not, but at least we need to know what will be changed and what will stay
> stable?
--
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
