hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Binglin Chang (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HADOOP-8990) Some minor issus in protobuf based ipc
Date Mon, 29 Oct 2012 06:59:12 GMT
Binglin Chang created HADOOP-8990:
-------------------------------------

             Summary: 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 RpcPayLoadHeader, 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 RpcPayloadHeader includes callId, but in rpc response callId is included in
RpcResponseHeader, and there is also HadoopRpcRequestHeader, 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

Mime
View raw message