[
https://issues.apache.org/jira/browse/DRILL-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045083#comment-16045083
]
Jinfeng Ni commented on DRILL-5547:
-----------------------------------
What discussed here seems to be initialization of system options in a Drill
cluster. Such step is a one time step after installation of Drill cluster. Use
should explicitly "load" a customer-build configuration into Drill cluster, by
issuing some specific command. This command does not require Drill cluster
running. All it needs to know is the configuration file, and the persistent
store Drill cluster uses to store system option. It makes sense that we could
leverage the existing DrillConfig system to parse the customized configuration.
However, in the regular code, we should not mix the two config systems. In
either planning time, or execution time, we should not check both
system/session option and configuration in DrillConfig. Sounds to me the
example of code gen compiler, which checks both options and configuration, is
a bug.
In summary, it makes sense to leverage DrillConfig to {{initialize}} and
{{load}} system options from a configuration file. But seems to me we should
not check both options and configuration in regular code path.
> Drill config options and session options do not work as intended
> ----------------------------------------------------------------
>
> Key: DRILL-5547
> URL: https://issues.apache.org/jira/browse/DRILL-5547
> Project: Apache Drill
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.10.0
> Reporter: Karthikeyan Manivannan
> Assignee: Venkata Jyothsna Donapati
> Fix For: Future
>
>
> In Drill, session options should take precedence over config options. But
> several of these session options are assigned hard-coded default values when
> the option validators are initialized. Because of this config options will
> never be read and honored even if the user did not specify the session
> option.
> ClassCompilerSelector.JAVA_COMPILER_VALIDATOR uses CompilerPolicy.DEFAULT as
> the default value. This default value gets into the session options map via
> the initialization of validators in SystemOptionManager.
> Now any piece of code that tries to check if a session option is set will
> never see a null, so it will always use that value and never try to look into
> the config options. For example, in the following piece of code from
> ClassCompilerSelector (), the policy will never be read from the config file.
> policy = CompilerPolicy.valueOf((value != null) ?
> value.string_val.toUpperCase() :
> config.getString(JAVA_COMPILER_CONFIG).toUpperCase());
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
