[
https://issues.apache.org/jira/browse/HADOOP-9151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537307#comment-13537307
]
Todd Lipcon commented on HADOOP-9151:
-------------------------------------
bq. I agree that if possible we should avoid breaking the compatibility. But
when a cleanup can make the implementation lot more clear, I prefer making that
change. That is the reason why we use alpha and any one who uses that release
should be ready to adopt the changes.
The implementation is slightly more clear, I agree. We should have done it this
way to begin with. But IMO it's really not worth it.
There are now downstream projects building against Hadoop-2 releases such as
HBase. If we break compat between 2.0.2 and a later release, then HBase users
will have the messy "make sure you replace your HDFS client jar inside HBase's
lib directory with the exact right version or else get weird error messages"
nonsense come back again.
I'd be +1 on this for 3.0 but not for branch-2, unless you can figure out some
way of maintaining a compatibility path. For example, we could do something
like this in 2.0:
- add an optional flag to the request protobuf indicating that the new style
exception response is supported
- mark the embedded exception
- new server checks the flag: if the flag is there, it sends the new-style
(in-PB) exception response. If it is not there, it uses the old style response
for compatibility
- when the new client gets an ERROR response, but exceptionClassName is not
found in the response PB, then it knows it is an old style server, and reads
the writables following the response (like the old protocol)
This would be compatible as follows:
- old client -> old server: obviously compatible
- old client -> new server: doesn't send flag, so new server responds with old
response
- new client -> old server: sends flag, but the old server ignores it (since
it's part of a PB, this is automatic). server responds with old style response.
- new client -> new server: sends flag, so new server responds with new style
response.
Obviously, all this makes the code more complex. So, I think it would be better
to just leave branch-2 alone, and make the improvement in branch-3/trunk.
> Include RPC error info in RpcResponseHeader instead of sending it separately
> ----------------------------------------------------------------------------
>
> Key: HADOOP-9151
> URL: https://issues.apache.org/jira/browse/HADOOP-9151
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Sanjay Radia
> Assignee: Sanjay Radia
> Attachments: HADOOP-9151.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
