Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 5484 invoked from network); 27 May 2009 16:44:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 May 2009 16:44:56 -0000 Received: (qmail 65463 invoked by uid 500); 27 May 2009 16:45:08 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 65403 invoked by uid 500); 27 May 2009 16:45:08 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 65384 invoked by uid 99); 27 May 2009 16:45:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 May 2009 16:45:08 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 May 2009 16:45:06 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id B102829A0015 for ; Wed, 27 May 2009 09:44:45 -0700 (PDT) Message-ID: <1748558349.1243442685724.JavaMail.jira@brutus> Date: Wed, 27 May 2009 09:44:45 -0700 (PDT) From: "Hemanth Yamijala (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-5919) Memory management variables need a backwards compatibility option after HADOOP-5881 In-Reply-To: <69949765.1243403205583.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713638#action_12713638 ] Hemanth Yamijala commented on HADOOP-5919: ------------------------------------------ In a brief discussion I had with Owen, he suggested that we use this patch as an opportunity to provide a facility in the configuration API to handle deprecated configuration variables. The basic idea is to have a Map in the Configuration class that would be statically defined and populated. The key is the deprecated config, and the value is a list of replacement configs (in plural because there are instances as in HADOOP-5881, where a single key is split into two for e.g. memory-per-slot into memory-per-map-slot and memory-per-reduce-slot). When a get is done on a deprecated key, this Configuration API will print a deprecation warning, and return the value of the first string in the list. When a set is done, likewise, the API will print a deprecation warning and set all the values in the replacement keys. In cases where there is no replacement, we could print an ERROR message and return null maybe, or throw an exception. Thoughts ? > Memory management variables need a backwards compatibility option after HADOOP-5881 > ----------------------------------------------------------------------------------- > > Key: HADOOP-5919 > URL: https://issues.apache.org/jira/browse/HADOOP-5919 > Project: Hadoop Core > Issue Type: Bug > Components: mapred > Reporter: Hemanth Yamijala > Priority: Blocker > > HADOOP-5881 modified variables related to memory management without looking at the backwards compatibility angle. This JIRA is to adress the gap. Marking it a blocker for 0.20.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.