hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milind Bhandarkar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-252) add versioning to RPC
Date Wed, 12 Jul 2006 23:24:30 GMT
    [ 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message