[
https://issues.apache.org/jira/browse/MAPREDUCE-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193003#comment-14193003
]
Zhijie Shen commented on MAPREDUCE-6052:
----------------------------------------
bq. Let's keep it here. We do can have flexibility in future for switching job
working directory or changing replication number. Also, combining two methods
don't have significant benefits, let's along existing copyAndConfigureFiles()
except we have strong justification for change.
bq. It is safety to keep checking directory existing before using it given the
possible refactoring or other operations in parallel.
There's unnecessary code duplication though executing it multiple times doesn't
result in bug, which is better to be cleanup. In fact, the replication number
and the working dir is read once, and used for all the following files/jars in
distributed caches. It's should have no problem to reuse it for log4j. And
during copying files/jars, this configured replication number and working dir
shouldn't be changed, and don't make sense to be concurrently modified by
others.
After the redundant code is removed, one method contains so few statements that
can be put directly into the other one, but I'm okay if you want to keep
separate them.
bq. two files with the same name on classpath (one is loading in conf directory
by default, the other is ), which one would take effective?
If so, probably we are going to still use the default
{{container-log4j.properties}} because it comes with
hadoop-yarn-server-nodemanager-2.x.y.jar. It will be good if we can document
this issue somewhere, in case we run into this issue later.
> Support overriding log4j.properties per job
> -------------------------------------------
>
> Key: MAPREDUCE-6052
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6052
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Junping Du
> Assignee: Junping Du
> Attachments: MAPREDUCE-6052-v2.patch, MAPREDUCE-6052-v3.patch,
> MAPREDUCE-6052-v4.patch, MAPREDUCE-6052.patch
>
>
> For current MR application, the "log4j.configuration" is hard coded to
> container-log4j.properties within each node. We still need flexibility to
> override it per job like what we do in MRV1.
> {code}
> public static void addLog4jSystemProperties(
> String logLevel, long logSize, int numBackups, List<String> vargs) {
> vargs.add("-Dlog4j.configuration=container-log4j.properties");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
