Return-Path: X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 73659E48B for ; Tue, 22 Jan 2013 17:32:14 +0000 (UTC) Received: (qmail 72213 invoked by uid 500); 22 Jan 2013 17:32:14 -0000 Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org Received: (qmail 72179 invoked by uid 500); 22 Jan 2013 17:32:14 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-issues@hadoop.apache.org Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 72162 invoked by uid 99); 22 Jan 2013 17:32:14 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jan 2013 17:32:14 +0000 Date: Tue, 22 Jan 2013 17:32:13 +0000 (UTC) From: "Luke Lu (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-9160) Adopt JMX for management protocols MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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