[
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
