Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <298427242.1244036647966.JavaMail.jira@brutus>
Date: Wed, 3 Jun 2009 06:44:07 -0700 (PDT)
From: "Hemanth Yamijala (JIRA)" <jira@apache.org>
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


    [ https://issues.apache.org/jira/browse/HADOOP-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715923#action_12715923 ] 

Hemanth Yamijala commented on HADOOP-5919:
------------------------------------------

In some more discussion, we found some problems in the proposed approach. Primarily, two problems:

- If the list of deprecated configurations is centralized in the Configuration class, what happens after project split ? So, if I have to deprecate a configuration of mapred, should I submit a patch to core ? And since theoretically they can have different release cycles, would that not conflict with requirements of different projects.

- Another problem is that the mapping as proposed above seems simplistic for some cases. For e.g. consider the split of number of slots into map slots and reduce slots that happened a couple of releases back. If some change like that needs to be supported, just setting the same value to both map slots and reduce slots seems incorrect. A better mapping could be to split half of them into map slots and half into reduce slots. In other words, it seems like we may need a more complex mapping mechanism.

Given all these, I am thinking this should definitely be the subject on another JIRA, as people might have more comments on the approach.

And since this bug is a blocker for 0.20.1, I suggest we do a mapping specifically in the relevant classes for this bug (the memory related classes) and move over to using a centralized framework for deprecating configurations once the configuration JIRA is made available.

Does this make sense ?

> 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
>            Assignee: rahul k singh
>            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.