Details

Description

The idea is that for getProtocolVersion, NameNode checks if the client and server versions are compatible if the server version is greater than the client version. If no, throws a VersionIncompatible exception; otherwise, returns the server version.

On the dfs client side, when creating a NameNode proxy, catches the VersionMismatch exception and then checks if the client version and the server version are compatible if the client version is greater than the server version. If not compatible, throws exception VersionIncomptible; otherwise, records the server version and continues.

If I understand the patch correctly, it still requires an exact version match by default. That seems good. What I don't understand is how you expect that to be altered. Do you expect folks to update the implementation of ProtocolCompatible as protocols evolve? Perhaps you can give some examples of how you expect this to work?

Since there's more than one protocol in HDFS, do you expect to add more methods to ProtocolCompatible for each protocol?

Doug Cutting
added a comment - 09/Aug/10 18:26 If I understand the patch correctly, it still requires an exact version match by default. That seems good. What I don't understand is how you expect that to be altered. Do you expect folks to update the implementation of ProtocolCompatible as protocols evolve? Perhaps you can give some examples of how you expect this to work?
Since there's more than one protocol in HDFS, do you expect to add more methods to ProtocolCompatible for each protocol?

> Do you expect folks to update the implementation of ProtocolCompatible as protocols evolve?
Yes that's exactly what I expect developers to update.

> Since there's more than one protocol in HDFS, do you expect to add more methods to ProtocolCompatible for each protocol?
This is going to be done on need basis. For this jira, I intend to support only ClientProtocol (client & NameNode) compatibility.

Hairong Kuang
added a comment - 10/Aug/10 00:29 > Do you expect folks to update the implementation of ProtocolCompatible as protocols evolve?
Yes that's exactly what I expect developers to update.
> Since there's more than one protocol in HDFS, do you expect to add more methods to ProtocolCompatible for each protocol?
This is going to be done on need basis. For this jira, I intend to support only ClientProtocol (client & NameNode) compatibility.

Thanks for elaborating. This patch seems fine: it's simple and does not alone introduce significant risk.

However subsequent changes to ProtocolCompatible will need to be carefully reviewed and tested. We don't yet have a testing framework to do that. So we're delaying that work (interoperability testing of different versions) until we actually have two versions that are meant to interoperate. This is a technical debt will be due in full the first time ProtocolCompatible is altered, I think.

Doug Cutting
added a comment - 13/Aug/10 17:57 Thanks for elaborating. This patch seems fine: it's simple and does not alone introduce significant risk.
However subsequent changes to ProtocolCompatible will need to be carefully reviewed and tested. We don't yet have a testing framework to do that. So we're delaying that work (interoperability testing of different versions) until we actually have two versions that are meant to interoperate. This is a technical debt will be due in full the first time ProtocolCompatible is altered, I think.