hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jay vyas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-5902) JobHistoryServer (HistoryFileManager) needs more debug logs.
Date Sat, 24 May 2014 01:40:01 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007959#comment-14007959

jay vyas commented on MAPREDUCE-5902:

After Further investigation, it appears that files with {{ % escape characters }} in them
arent picked up by the JobHistoryServer.  I'd like the opinion of one of the JobHistoryServer
authors to confirm/deny wether jobnames are indeed allowed to include {{"%"}} signs in them,
i.e. {{name%-myName}}.  

Has anyone else seen this before?  I'd be somewhat surprised if I was the only person who
has run into it .... I can't imagine its a configuration error of any sort?

The below files appear to be "stuck" in mr-history "purgatory", neither are they detectable
as completed jobs from a REST request {{ curl
| python -mjson.tool }} to the JobHistoryServer API, **nor** are they ever moved to {{/mr-history/done/}}


> JobHistoryServer (HistoryFileManager) needs more debug logs.
> ------------------------------------------------------------
>                 Key: MAPREDUCE-5902
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5902
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: jobhistoryserver
>            Reporter: jay vyas
>   Original Estimate: 1h
>  Remaining Estimate: 1h
> With the JobHistory Server , it appears that its possible sometimes to skip over certain
history files.  I havent been able to determine why yet, but I've found that some long named
.jhist files aren't getting collected into the done/ directory.
> After tracing some in the actual source, and turning on DEBUG level logging, it became
clear that this snippet is an important workhorse (scanDirectoryForIntermediateFiles, and
scanDirectoryForHistoryFiles ultimately boil down to scanDirectory()).  
> It would be extremely useful , then, to have a couple of gaurded logs at this level of
the code, so that we can see, in the log folders, why files are being filtered out  , i.e.
it is due to filterint or visibility.
> {noformat}
>   private static List<FileStatus> scanDirectory(Path path, FileContext fc,
>       PathFilter pathFilter) throws IOException {
>     path = fc.makeQualified(path);
>     List<FileStatus> jhStatusList = new ArrayList<FileStatus>();
>     RemoteIterator<FileStatus> fileStatusIter = fc.listStatus(path);
>     while (fileStatusIter.hasNext()) {
>       FileStatus fileStatus = fileStatusIter.next();
>       Path filePath = fileStatus.getPath();
>       if (fileStatus.isFile() && pathFilter.accept(filePath)) {
>         jhStatusList.add(fileStatus);
>       }
>     }
>     return jhStatusList;
>   }
> {noformat}

This message was sent by Atlassian JIRA

View raw message