[
https://issues.apache.org/jira/browse/HADOOP-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Lu updated HADOOP-9160:
----------------------------
Description:
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.
was:
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.
> 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
