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

Jason Lowe commented on YARN-2730:
----------------------------------

Thanks for the patch, Siqi.

We could go two ways with this.  We should be able to solve it without 
modifying FileContext at all by having startLocalizer create a clone like this:

{code}
  FileContext localizerFc = 
FileContext.getFileContext(lfs.getDefaultFilesytem(), getConf());
  localizerFc.setUMask(lfs.getUMask());
{code}

Or we could add a cloning ability to FileContext directly, like this patch.  If 
we continue with that route then we need to clone everything in case the clone 
method is used elsewhere.  The workingDir is not copied, and thus it isn't a 
true clone.  One might want to clone a filecontext just to modify the umask, 
for example, and therefore callers would expect the working directory to be 
preserved during the clone.

TestFileContext: Configuration and StringUtils are unused imports.

Nit: some original lines that were formatted for 80 columns no longer are after 
the changes.


> Only one localizer can run on a NodeManager at a time
> -----------------------------------------------------
>
>                 Key: YARN-2730
>                 URL: https://issues.apache.org/jira/browse/YARN-2730
>             Project: Hadoop YARN
>          Issue Type: Bug
>    Affects Versions: 2.4.0
>            Reporter: Siqi Li
>            Assignee: Siqi Li
>            Priority: Critical
>         Attachments: YARN-2730.v1.patch
>
>
> We are seeing that when one of the localizerRunner stuck, the rest of the 
> localizerRunners are blocked. We should remove the synchronized modifier.
> The synchronized modifier appears to have been added by 
> https://issues.apache.org/jira/browse/MAPREDUCE-3537
> It could be removed if Localizer doesn't depend on current directory



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to