[ 
http://issues.apache.org/jira/browse/HADOOP-252?page=comments#action_12420748 ] 

Milind Bhandarkar commented on HADOOP-252:
------------------------------------------

I have started thinking about this issue. Here is my proposal so far:

There are 6 protocols that use RPC in hadoop. One is in test, and 5 in source. 
These are interfaces that are implemented by servers. We modify these 
interfaces to inherit from a common interface, called VersionedProtocol. 
VersionedProtocol has exactly one method:

long getProtocolVersion()

The client tries to get a proxy via RPC.getProxy in the setup phase, and passes 
the required interface class.
This method, upon successfully obtaining the proxy, casts it to 
VersionedProtocol, calls its getProtocolVersion, compares it with the passed in 
interface's static final long versionID field, and fails if they do not match.

I think we should not use computed-by-default serialVersionUID field, since it 
can change even if you sneeze at the class :-) Also, since we do not use 
serialization runtime to calculate this hash, we are not attached to the name 
as well. This version needs to change in case of any interface changes to the 
protocol.

The client, upon version mismatch, prints out an error, and exits cleanly. The 
server blissfully remains unaware of that.

The objective of this is not to handle backward compatibility, but to detect 
and fail fast and cleanly if there is a version mismatch between client and 
server.


> add versioning to RPC
> ---------------------
>
>          Key: HADOOP-252
>          URL: http://issues.apache.org/jira/browse/HADOOP-252
>      Project: Hadoop
>         Type: Improvement

>   Components: ipc
>     Versions: 0.3.0
>     Reporter: Yoram Arnon
>      Fix For: 0.5.0

>
> currently, any change to any rpc message breaks the protocol, with mysterious 
> exceptions occurring at run time.
> a versioning sceme would have two benefits:
> - intelligent error messages, indicating that an upgrade is required
> - backwards compatibility could be supported.
> the proposal is to add a "const version" for each protocol, and a method: int 
> getVersion(int version) that sends the client's version and receives the 
> server's version. This would be the first method invoked on connection. Both 
> sides then either agree on the lowest version number, providing backwards 
> compatibility support, or abort the connection as "unsupported version".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to