You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Hemanth Yamijala (JIRA)" <ji...@apache.org> on 2009/05/27 18:44:45 UTC

[jira] Commented: (HADOOP-5919) Memory management variables need a backwards compatibility option after HADOOP-5881

    [ 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<String, String[]> 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.