[
https://issues.apache.org/jira/browse/HADOOP-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538241#comment-13538241
]
Luke Lu commented on HADOOP-9160:
---------------------------------
Great feedback guys. Changed the title to reflect new proposal of JMX as an
alternative protocols for existing admin ops and preferred protocols for new
admin ops.
bq. 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.
Again, the redundant/separate mechanism is good thing for admin protocols. JMX
supports the standard SSL client cert auth out of the box, which is similar to
kinit with a keytab. While Hadoop security requires a complex 3 way exchanges
between KDC, service and client, that's fairly challenging to debug (in case of
network/firewall issues). SSL is a simple two-way handshake that's fairly
straight forward to debug with wireshark. It's not exactly a piece of cake but
a walk in the park compared with Hadoop security. Don't you think it's a good
thing that you can admin the cluster when KDC flakes out?
For more elaborate installation. One would use a client cert on a admin console
with all the pluggable auth goodies. Now where do I send the bill? :)
bq. 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
How can adding JMX which doesn't impact production code paths be more work? A
typical admin service example in JMX:
{code}
interface SomeAdminMXBean {
void someAdminOp();
void getSomeAdminValue();
void setSomeAdminValue();
}
class SomeAdminService implements SomeAdminMXBean {
...
}
MBeans.register("SomeAdminService", someAdminServiceInstance);
{code}
That's all on the Hadoop side. No code gen, no client side recompilation
required. You can fire up jconsole for dev/debug, or use builtin or plugin jmx
support in Eclipse, NetBeans, IntelliJ etc.
bq. Lastly, though JMX is a standard, in my experience there isn't "wide client
support".
JMX is pretty much supported by all commercial java management software. A few
open source examples that good pretty good feedback:
* [jManage|http://www.jmanage.org/] - full admin console with command line
support.
* [jminix|https://code.google.com/p/jminix/] - a simple, embeddable, restful,
JMX console.
* [jmxcmd|http://sourceforge.net/projects/jmxcmd/] - a simple jmx command line
tool (only a 11kB jar!)
* [jmxterm|http://wiki.cyclopsgroup.org/jmxterm] - a jmx command shell with
optional interactive mode with command completion.
I think it's unreasonable to call JMX tooling "pretty bad", simply because you
cannot find a particular choice that fit your preference perfectly.
> Adopt JMX for management protocols
> ----------------------------------
>
> 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 is few external tools depending on it. We can keep the
> old protocol for as long as needed. New commands will be in JMX. The
> transition can be gradual and backward-compatible.
--
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
