[
https://issues.apache.org/jira/browse/HADOOP-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akira Ajisaka reassigned HADOOP-15477:
--------------------------------------
Assignee: Johan Gustavsson
> Make unjar in RunJar overrideable
> ---------------------------------
>
> Key: HADOOP-15477
> URL: https://issues.apache.org/jira/browse/HADOOP-15477
> Project: Hadoop Common
> Issue Type: Improvement
> Affects Versions: 2.8.3, 2.9.1, 2.7.6, 3.0.2
> Reporter: Johan Gustavsson
> Assignee: Johan Gustavsson
> Priority: Trivial
> Attachments: HADOOP-15477.001.patch, HADOOP-15477.002.patch,
> HADOOP-15477.003.patch, HADOOP-15477.004.patch
>
>
> Currently Hadoop's RunJar will unjar the jar provided and look for any jars
> inside and add them to the classpath. Since most deployments doesn't use jar
> in jar, but rather uberjars this could be rather time consuming at times and
> can cause issues related to over consumption of inodes, for something that is
> in many cases is not used.
> For that purpose there should be an env variable to disable this behavior.
>
> Edit: As requested by [~ajisakaa] in person here is a more detailed
> description of the issues we are trying to solve with this.
> A good chunk of our workloads are packaged in an uberjar, and are launched as
> a separate process using the {{hadoop jar}} cli. This is has generally been
> working out pretty well historically, with sub second launch times and good
> client isolation. Since bumping the host OS to a version patched with
> Meltdown/Specter patches we do see from time to time load becoming very high
> even with only a few client processes running and a single unjar process
> taking up to 10min.
> While another simple approach would be to abandon using the {{hadoop jar}}
> cli this would most likely take a lot more work than simply disabling unjar
> for the time being.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
