[MAPREDUCE-6719] The list of -libjars archives should be replaced with a wildcard in the distributed cache to reduce the application footprint in the state store

• Type: Improvement
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.8.0
• Fix Version/s: 2.9.0, 3.0.0-alpha1
• Component/s: distributed-cache
• Hadoop Flags: Reviewed
• Assignee: Daniel Templeton
• Reporter: Daniel Templeton
• Created: 20/Jun/16 14:07
• Updated: 11/Dec/18 21:17
• Resolved: 21/Jun/16 18:30

Description

When using the -libjars option to add classes to the classpath, every library so added is explicitly listed in the ContainerLaunchContext's local resources even though they're all uploaded to the same directory in HDFS. When using tools like Crunch without an uber JAR or when trying to take advantage of the shared cache, the number of libraries can be quite large. We've seen many cases where we had to turn down the max number of applications to prevent ZK from running out of heap because of the size of the state store entries.
This JIRA proposes to allow for wildcards both in the internal processing of the -libjars switch and in paths added through the Job and DistributedCache classes. Rather than listing all files independently, this JIRA proposes to replace the complete list of libdir files with the wildcarded libdir directory, e.g. "libdir/*". This behavior is the same as the current behavior when using -libjars, but avoids explicitly listing every file.
This capability will also be exposed by the DistributedCache.addCacheFile() method.
See YARN-4958 for the NM side of the implementation and additional discussion.

Issue Links

• causes: MAPREDUCE-7172 Wildcard functionality of -libjar is broken when jars are located in same remote FS
• is related to: YARN-5388 Deprecate and remove DockerContainerExecutor
• requires: YARN-4958 The file localization process should allow for wildcards to reduce the application footprint in the state store