[
https://issues.apache.org/jira/browse/HADOOP-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090469#comment-13090469
]
Chris Douglas commented on HADOOP-7573:
---------------------------------------
Experts should be able to diagnose a misconfiguration without this aid, or they
wouldn't be experts. But your point about reproducing the configuration that
produced the problem is salient. Since the Apache release isn't oriented to a
support org, I'd lean toward disabling/leaving it at DEBUG/TRACE. A support org
can enable it as policy or request a run with this enabled.
Without auditing its use in the servers it's hard to say whether the
per-instanceness is actually wrong. Particularly in TaskTrackers, it's common
practice to set "final" on stuff the user config shouldn't change. While the
TT/user configs are reasonably sorted out internally, it'd be useful to know if
a job wrote over a value that should be immutable. Or if something is immutable
that shouldn't be.
But to be honest, I remain skeptical. "Debugging" is an impossibly pervasive
use case justifying infinitely many hooks, but installing a println in the
configuration system to cast the widest net is awfully inexact.
> hadoop should log configuration reads
> -------------------------------------
>
> Key: HADOOP-7573
> URL: https://issues.apache.org/jira/browse/HADOOP-7573
> Project: Hadoop Common
> Issue Type: Improvement
> Components: conf
> Affects Versions: 0.20.203.0
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Priority: Minor
> Fix For: 0.20.206.0
>
> Attachments: HADOOP-7573.patch, HADOOP-7573.patch
>
>
> For debugging, it would often be valuable to know which configuration options
> ever got read out of the Configuration into the rest of the program -- an
> unread option didn't cause a problem. This patch logs the first time each
> option is read.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
