[ https://issues.apache.org/jira/browse/HADOOP-9151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537477#comment-13537477 ]
Todd Lipcon commented on HADOOP-9151: ------------------------------------- bq. Not sure if I follow. When HBase is installed on top a Hadoop cluster doesn't it pickup the hadoop jars from the installed hadoop? Not always. If you download the HBase tarball, for example, and build it with the "Hadoop 2" profile, it will end up with its own copies of the hadoop jars. bq. Any plans to check this into Hadoop? This would be useful to the wider community and we can speed up libhdfs. The client is just a simple RPC client - not a full HDFS client, and I didn't get it to a really usable "production quality" state - just enough to do a "listFiles" on a running NN. I'll try to throw it up on github at some point. My point, though, was just to say that, even though this area of the protocol is slightly messy, it's by far not the biggest obstacle to writing foreign language implementations of RPC. bq. I understand that it could be messy for downstream projects. But that is what an alpha release tag is meant to indicate. BTW since 2.0.0-alpha we have had many incompatible changes as well As far as I know we have not broken RPC or API compatibility at all since 2.0.0, and I would be against any case where we do (not just this one). As for the labeling of alpha, I have been arguing against calling it alpha for several months, but there's no clear bylaws on how the labeling changes, etc. So, given that I can't change the labeling, I'll just represent my feelings on individual code changes - and this is one that I can't legitimately support on branch-2. In the spirit of full disclosure: wearing my Cloudera hat, we have a distribution based on the Hadoop 2 code line. We are not going to break wire compatibility within minor updates of this distribution. So, if branch-2 breaks compatibility, then our distro will become incompatible with branch-2, which is no good. Wearing my Apache hat: it would be nice if Cloudera, Hortonworks, Apache, and anyone else distributing "Hadoop 2" can remain fully wire- and API-compatible. If this change goes in, it will serve to fracture the ecosystem more, and make it harder for the community to move freely between different versions. I imagine other distributors would much prefer that all distros are wire-compatible, since it makes it easier, for example, for one of our customers to go and work with another vendor without rebuilding all their code with a new client jar (one of the main points of value in open source!) So, to be clear, -1 on this change for branch-2 unless there is a compatibility path. > 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