[
https://issues.apache.org/jira/browse/HADOOP-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896178#action_12896178
]
Doug Cutting commented on HADOOP-6904:
--------------------------------------
I think the long-term plan is to try to avoid version incompatibilities. With
Avro-based RPC (HADOOP-6659) we could:
- handle the addition of new parameters and fields with reasonable default
values
- handle changes to method semantics by adding new methods with the new
semantics (eventually perhaps removing the old methods).
We'd still need to be careful to design and test for back-compatibility, and
only, e.g., make sure new parameters and fields have good defaults, add new
methods when semantics change, and only remove an old method in a major release
where we're willing to lose some back-compatibility. This approach might not
need an explicit check of which versions are compatible, since Avro could
detect the missing method.
Unfortunately work on HADOOP-6659 has been stopped by a veto.
The approach you propose here could be useful until work on HADOOP-6659 is
resumed, and may be even useful afterwards, as it might permit more concise
incompatibility errors. It's not a very large or complex change, so I don't
see it creating a lot of risk or adding significant maintenance costs.
> 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: rpcVersion.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.
