hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9151) Include RPC error info in RpcResponseHeader instead of sending it separately
Date Thu, 20 Dec 2012 23:23:13 GMT

    [ 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

Mime
View raw message