[ 
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.

Reply via email to