You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by "Wangda Tan (JIRA)" <ji...@apache.org> on 2018/12/11 21:17:00 UTC
[jira] [Created] (MAPREDUCE-7172) Wildcard functionality of -libjar
is broken when jars are located in same remote FS
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)
{code:java}
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);
}{code}
However, in the same method, specified resources will be only uploaded when two FSes are different, see copyRemoteFiles:
{code:java}
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:
{code:java}
hadoop jar abc.jar org.ABC -libjars "wasb://host/path1/jar1,wasb://host/path2/jar2..."{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org