hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hemanth Yamijala (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-5919) Memory management variables need a backwards compatibility option after HADOOP-5881
Date Thu, 04 Jun 2009 06:10:07 GMT

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

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

Discussed with Owen on the issues. 

We think the project split is a knotty issue and may need a resolution that merits further
discussion in a separate JIRA. But we do have a solution that we think will work. Hence for
the purpose of this jira, we are still proposing to go ahead with introducing the deprecated
mapping. And handle the project split issue in a follow-up jira, maybe for Hadoop 0.21.

Regarding the second point of a more complicated mapping, again we agree that valid use cases
for this could exist. We think it is not necessary for the deprecation map approach to handle
every single deprecation in configuration. In other words, if a complicated use case exists,
it could be done by the application itself - outside the configuration API. Or an extension
to the deprecation mechanism can also be looked at as a further enhancement.

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


Mime
View raw message