You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Chris Douglas (JIRA)" <ji...@apache.org> on 2013/05/07 08:21:16 UTC

[jira] [Comment Edited] (YARN-45) Scheduler feedback to AM to release containers

    [ https://issues.apache.org/jira/browse/YARN-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650527#comment-13650527 ] 

Chris Douglas edited comment on YARN-45 at 5/7/13 6:20 AM:
-----------------------------------------------------------

bq. Would be great if you could add a version number to your patches.

Sorry, we weren't sure of the current convention.

{quote}
 - PreemptionMessage.strict should perhaps be named strictContract
explicitly. You did name the setters and the getters verbosely which
is good.
 - You should mark all the api getters and setters to be synchronized.
There are similar locking bugs in other existing records too but we
are tracking them elsewhere.
 - PreemptionContainer.getId() - Javadoc should refer to containers
instead of Resource?
 - PreemptionContract.getContainers() - Javadoc referring to
"<code>ResourceManager</code> may also include a @link
PreemptionContract that, if satisfied, may replace these" doesn't make
sense to me.
{quote}

Fixed all of these; last one was a copy/paste of an older version of
the code. Thanks for catching these.

[~bikassaha]: we took another attempt at the javadoc, but it's
probably still not sufficient. We opened YARN-650 to track
documentation of this feature in the AM how-to, which we'll address
presently.

(thanks everyone for the great feedback!)

                
      was (Author: curino):
    bq. Would be great if you could add a version number to your patches.

Sorry, we weren't sure of the current convention.

{quote}
 - PreemptionMessage.strict should perhaps be named strictContract
explicitly. You did name the setters and the getters verbosely which
is good.
 - You should mark all the api getters and setters to be synchronized.
There are similar locking bugs in other existing records too but we
are tracking them elsewhere.
 - PreemptionContainer.getId() - Javadoc should refer to containers
instead of Resource?
 - PreemptionContract.getContainers() - Javadoc referring to
"<code>ResourceManager</code> may also include a @link
PreemptionContract that, if satisfied, may replace these" doesn't make
sense to me.
{quote}

Fixed all of these; last one was a copy/paste of an older version of
the code. Thanks for catching these.

[~bikassaha]: we took another attempt at the javadoc, but it's
probably still not sufficient. We opened YARN-XXX to track
documentation of this feature in the AM how-to, which we'll address
presently.

(thanks everyone for the great feedback!)

                  
> Scheduler feedback to AM to release containers
> ----------------------------------------------
>
>                 Key: YARN-45
>                 URL: https://issues.apache.org/jira/browse/YARN-45
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>            Reporter: Chris Douglas
>            Assignee: Carlo Curino
>             Fix For: 2.0.5-beta
>
>         Attachments: YARN-45.1.patch, YARN-45.patch, YARN-45.patch, YARN-45.patch, YARN-45.patch, YARN-45.patch, YARN-45.patch, YARN-45_summary_of_alternatives.pdf
>
>
> The ResourceManager strikes a balance between cluster utilization and strict enforcement of resource invariants in the cluster. Individual allocations of containers must be reclaimed- or reserved- to restore the global invariants when cluster load shifts. In some cases, the ApplicationMaster can respond to fluctuations in resource availability without losing the work already completed by that task (MAPREDUCE-4584). Supplying it with this information would be helpful for overall cluster utilization [1]. To this end, we want to establish a protocol for the RM to ask the AM to release containers.
> [1] http://research.yahoo.com/files/yl-2012-003.pdf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira