[
https://issues.apache.org/jira/browse/DRILL-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084780#comment-16084780
]
Paul Rogers commented on DRILL-5547:
------------------------------------
Yes. Of course, the current (Drill 1.10) version requires all the Drillbits to
have the same, identical Drill jar files since the defaults are set in Java
code. If Drill 1.9 had one hard-coded value, and Drill 1.10 had another, then a
mixed cluster of Drill 1.9 and Drill 1.10 servers will have the issue you are
concerned about.
So, we have to address the inconsistent default issue in order to support
rolling upgrades (which requires that two Drill versions run in the same
cluster.)
One way to do this is to use the defaults from the oldest Drillbit. Or, we can
figure out some other solution.
Note that, as discussed elsewhere, the purpose of this is *not* for users to
change the defaults. They can already do so much more simply by issuing an
`ALTER SESSION` command. The purpose of this is to:
* Externalize constants
* Allow Drill distributions to assign distribution-specific values without
having to have custom code versions.
> 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.4.14#64029)
