hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wangda Tan (JIRA)" <j...@apache.org>
Subject [jira] [Created] (MAPREDUCE-7172) Wildcard functionality of -libjar is broken when jars are located in same remote FS
Date Tue, 11 Dec 2018 21:17:00 GMT
Wangda Tan created MAPREDUCE-7172:

             Summary: Wildcard functionality of -libjar is broken when jars are located in
same remote FS
                 Key: MAPREDUCE-7172
                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-7172
             Project: Hadoop Map/Reduce
          Issue Type: Bug
            Reporter: Wangda Tan

We recently found that when -libjar specified jars on the same remote FS, jars will not be
properly added to classpath. 

The reason is MAPREDUCE-6719 added the wildcard functionality, but the follow logic assumes
files are all placed under job's submission directory. (Inside JobResourceUploader)
if (useWildcard && !foundFragment) {
  // Add the whole directory to the cache using a wild card
  Path libJarsDirWildcard =
      jtFs.makeQualified(new Path(libjarsDir, DistributedCache.WILDCARD));
  DistributedCache.addCacheFile(libJarsDirWildcard.toUri(), conf);
However, in the same method, specified resources will be only uploaded when two FSes are different,
see copyRemoteFiles:
if (FileUtil.compareFs(remoteFs, jtFs)) {
  return originalPath;
} {code}
Workaround of this issue is pass:

mapreduce.client.libjars.wildcard = false.

When the MR job got launched. 

Example commandline to reproduce this issue is: 
hadoop jar abc.jar org.ABC -libjars "wasb://host/path1/jar1,wasb://host/path2/jar2..."{code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

View raw message