[
https://issues.apache.org/jira/browse/HADOOP-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978514#action_12978514
]
Doug Cutting commented on HADOOP-6904:
--------------------------------------
Looks good. Some comments on the current patch:
- Method#hashCode() hashes the method's declaring class and the method name.
Rather we probably want the hash of the method name (since we only send that on
the wire) and the names of the types of its parameters. I guess we require
that if someone changes the serialization of a parameter that they'll manually
increment the protocol version number?
- longs might be better to use than ints for method hashcodes, to better
prevent collisions
- can ProtocolServer become ProtocolServer<T> where T is the proxied interface?
- most of the implementation of
TestRPCCompatiblity.testImpl0#getProtocolVersion might be a public static
utility method, like, RPC.getProtocolSignature(Class<?> interface).
- The terms ProtocolVersion and ProtocolInfo are both used for the same
concept. We might rename ProtocolInfo to ProtocolSignature and
getProtocolVersion to getProtocolSignature?
> A baby step towards inter-version RPC communications
> ----------------------------------------------------
>
> Key: HADOOP-6904
> URL: https://issues.apache.org/jira/browse/HADOOP-6904
> Project: Hadoop Common
> Issue Type: New Feature
> Components: ipc
> Affects Versions: 0.22.0
> Reporter: Hairong Kuang
> Assignee: Hairong Kuang
> Fix For: 0.22.0
>
> Attachments: majorMinorVersion.patch, majorMinorVersion1.patch,
> rpcCompatible-trunk.patch, rpcVersion.patch, rpcVersion1.patch
>
>
> Currently RPC communications in Hadoop is very strict. If a client has a
> different version from that of the server, a VersionMismatched exception is
> thrown and the client can not connect to the server. This force us to update
> both client and server all at once if a RPC protocol is changed. But sometime
> different versions do not mean the client & server are not compatible. It
> would be nice if we could relax this restriction and allows us to support
> inter-version communications.
> My idea is that DfsClient catches VersionMismatched exception when it
> connects to NameNode. It then checks if the client & the server is
> compatible. If yes, it sets the NameNode version in the dfs client and allows
> the client to continue talking to NameNode. Otherwise, rethrow the
> VersionMismatch exception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
