Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Message-ID: <9557670.270121294704348425.JavaMail.jira@thor>
Date: Mon, 10 Jan 2011 19:05:48 -0500 (EST)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-6904) A baby step towards inter-version
 RPC communications
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979860#action_12979860 ] 

Doug Cutting commented on HADOOP-6904:
--------------------------------------

If the client must provide an interface name that the server then uses to identify the set of methods to fingerprint then I don't see that adding the interface name to the fingerprint function would change semantics.  Or am I missing something?  It might even simplify some things, e.g., if the client's protocol fingerprint incorporated its protocol interface name then the fingerprint alone might be used to lookup cached server fingerprints.  Are there protocols where we don't intend to use service authentication, where clients don't provide the protocol interface name?  If so, that might argue against using the interface name in the protocol fingerprint.  Are there other reasons?

In the latest patch, we might better use ConcurrentHashMap for the fingerprint cache.  Also, we should probably mark the cache 'static final' and name it something like FINGERPRINT_CACHE.

> 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.23.0
>
>         Attachments: majorMinorVersion.patch, majorMinorVersion1.patch, rpcCompatible-trunk.patch, rpcCompatible-trunk1.patch, rpcCompatible-trunk2.patch, rpcCompatible-trunk4.patch, rpcCompatible-trunk5.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.