[
https://issues.apache.org/jira/browse/HADOOP-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968363#action_12968363
]
Doug Cutting commented on HADOOP-6904:
--------------------------------------
> Major number changes when you delete a method, change the signature of the
> method, of the serialization of the method.
Perhaps it would be simpler to state when it doesn't change. Are you
suggesting that the "major" version changes for any protocol change but the
addition of an all-new method name? That's the only permitted, compatible kind
of change to a protocol? That seems reasonable.
Note that, if a method is removed, one can decide between incrementing the
version or generating a runtime error when it's called on a case-by-case basis.
For a obsolete core method that should no longer be called by compatible
clients, incrementing the major would be appropriate. For a seldom-called
method that can no longer be supported, one might leave the version alone and
generate a runtime error to permit old clients to still operate in the majority
of cases.
> A baby step towards inter-version communications between dfs client and
> NameNode
> --------------------------------------------------------------------------------
>
> 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,
> 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.
