[
https://issues.apache.org/jira/browse/HADOOP-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537451#comment-13537451
]
Todd Lipcon commented on HADOOP-9160:
-------------------------------------
I have mixed feelings on this. On one hand, it would have been nice had we
started with JMX. But changing everything around now has some downsides:
First, I disagree with your assertion that there are no management tools
depending on the existing RPCs. Our products at Cloudera definitely do depend
on them, and there are also various APIs inside DistributedFileSystem which
would probably be classified as admin.
In terms of handling those APIs, we'd end up having to use a remote JMX client
in order to access the cluster. This is problematic in that it would use an
entirely separate authentication system from Hadoop RPC -- I don't know a ton
about JMX, but it appears to be user/password based? This begs the question of
how it should be configured, how one deals with the case where multiple users
should be able to admin the cluster, how to centrally manage it, etc. We've
already solved these problems (at least partially) with the existing auth
schemes and RPC, and we'd have to solve them again for JMX.
As for cross-version compatibility, I think pulling in a forward-compatible
protobuf implementation into branch-1 would actually be a similar (or less)
amount of work compared to overhauling all of the admin functionality to JMX,
and would have the other major advantage that we could potentially get some
basic client compatibility between hadoop 1 and 2, if someone were to do the
infrastructure work.
Lastly, though JMX is a standard, in my experience there isn't "wide client
support". Most of the tooling I've found around JMX is pretty bad, to be
honest, especially if you have management tools in languages other than Java.
For example, googling "python jmx client", the only methods I can find involve
putting a JMX-HTTP gateway on the server side, which means we're not really
getting a ton of mileage anyway.
> Change management protocol to JMX
> ---------------------------------
>
> Key: HADOOP-9160
> URL: https://issues.apache.org/jira/browse/HADOOP-9160
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Luke Lu
>
> Currently we use Hadoop RPC (and some HTTP, notably fsck) for admin
> protocols. We should consider moving all admin protocols to JMX, as it's the
> industry standard for java server management with wide client support.
> Having an alternative/redundant RPC mechanism is very desirable for admin
> protocols. I've seen in the past in multiple cases, where NN and/or JT RPC
> were locked up solid due to various bugs and/or RPC thread pool exhaustion,
> while HTTP and/or JMX worked just fine.
> Other desirable benefits include admin protocol backward compatibility and
> introspectability, which is convenient for a centralized management system to
> manage multiple Hadoop clusters of different versions. Another notable
> benefit is that it's much easier to implement new admin commands in JMX
> (especially with MXBean) than Hadoop RPC, especially in trunk (and 0.23+,
> 2.x).
> Since Hadoop RPC doesn't guarantee backward compatibility (probably not ever
> for branch-1), there are no external management tools depending on it. We can
> maintain a practical backward compatibility by keeping the admin
> script/command line interface unchanged.
--
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
