[
https://issues.apache.org/jira/browse/HADOOP-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541180#comment-13541180
]
Allen Wittenauer commented on HADOOP-9160:
------------------------------------------
bq. The fsck operation takes a long time to complete, could have lot of output
streamed as response for a long time.
HDFS-2538 fixes this problem: output is reduced, fsck runs faster, and it's
much easier for ops teams to build tools around. From a JMX perspective, it
would just need to provide a percentage.
I can understand the desire to do JMX. It's a defacto standard supported by
many industry tools. That said...
If we put admin interfaces in JMX, then we need to be concerned about security.
When I last looked at it, JMX requires the use of keystores full of certs in
order to handle multiple identities. PKI+keystores means a lot of pain on the
ops side of the house. So if we enable JMX for any 'writable' interfaces, we
need to have a way to turn it off so that those of us that don't want to go
through that pain and still have a secure system can stick with Hadoop RPC/HTTP
with GSSAPI/SPNEGO.
> 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 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
