[
https://issues.apache.org/jira/browse/HADOOP-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559789#comment-13559789
]
Luke Lu commented on HADOOP-9160:
---------------------------------
bq. I want the ability to turn off writes to guarantee that JMX can be used as
a read-only interface.
Not sure if you mean the JMX remote (via RMI) or JMX REST/JSON via Jolokia. My
guess is the latter as the former is supported by JMX itself, which you should
be using right now if you want read-only access. I'll include both for your
convenience :)
According to the 1st result ([the official documentation of
jmx|http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html#PasswordAccessFiles])
of the "jmx readonly" search query, you can setup multiple user(role)
passwords and corresponding access restrictions to "readonly" or "readwrite".
Jolokia, which is written by a sysadmin for sysadmins, has even finer grain of
access control to a subset of read, write, exec, list, search and version
commands, according to [the official documentation of
jolokia|http://www.jolokia.org/reference/html/security.html] with the
/jolokia-access.xml in class path.
I hope this addresses your concern, as read-only access does not depend on
hadoop developers to do the right thing in code/patches but ops to set the
right policies independent of hadoop or any specific applications, which is a
good thing, IMO.
> 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
> Attachments: hadoop-9160-demo-branch-1.txt
>
>
> Currently we use Hadoop RPC (and some HTTP, notably fsck) for admin
> protocols. We should consider adopt JMX for future admin protocols, 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 (as well as
> 0.23+ and 2.x).
> Since Hadoop RPC doesn't guarantee backward compatibility (probably not ever
> for branch-1), there are few external tools depending on it. We can keep the
> old protocols for as long as needed. New commands should 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
