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

Erik Steffl commented on HADOOP-6904:
-------------------------------------

Was it ever considered to take the capabilities approach instead of version 
checking?

See e.g. IMAP protocol for example (chose it as an example because it's a 
widely used protocol that has number of client and server implementations 
working successfully with each other), this looks like a fairly comprehensive 
link to protocol specs http://www.networksorcery.com/enp/protocol/imap.htm

Seems like as Hadoop matures it could make sense to provide a method for both 
client and server to negotiate how they talk to each other (and possibly adjust 
to each other). At this point the many implementation scenario is not valid yet 
but capabilities are useful anyway (cross version) and (very likely in my 
opinion) sooner or later we will get different implementations (happens with 
pretty much any successfull non-proprietary client/server system (even some 
proprietary ones)).

> 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, 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.

Reply via email to