[
https://issues.apache.org/jira/browse/HADOOP-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185364#comment-14185364
]
Colin Patrick McCabe commented on HADOOP-11223:
-----------------------------------------------
Interesting idea. Just to clarify, it seems like there are two separate ideas
here:
1. Some kind of read-only wrapper for Configuration, to make it impossible to
modify a given configuration object.
2. Avoiding re-reading the XML files more than once.
It seems like #2 could be accomplished pretty easily by having a
DefaultConfiguration.java that just had a public static Configuration object.
Then #1 is just a way of making sure that badly behaved programmers don't alter
this default configuration when they're using it. Is that an accurate summary?
+1 for both ideas from me. I often wish Configuration were an immutable class,
perhaps with copy-on-write semantics. It would eliminate a lot of race
conditions.
> Offer a read-only conf alternative to new Configuration()
> ---------------------------------------------------------
>
> Key: HADOOP-11223
> URL: https://issues.apache.org/jira/browse/HADOOP-11223
> Project: Hadoop Common
> Issue Type: Bug
> Components: conf
> Reporter: Gopal V
> Labels: Performance
>
> new Configuration() is called from several static blocks across Hadoop.
> This is incredibly inefficient, since each one of those involves primarily
> XML parsing at a point where the JIT won't be triggered & interpreter mode is
> essentially forced on the JVM.
> The alternate solution would be to offer a {{Configuration::getDefault()}}
> alternative which disallows any modifications.
> At the very least, such a method would need to be called from
> # org.apache.hadoop.io.nativeio.NativeIO::<clinit>()
> # org.apache.hadoop.security.SecurityUtil::<clinit>()
> # org.apache.hadoop.yarn.factory.providers.RecordFactoryProvider::<clinit>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
