drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5547) Drill config options and session options do not work as intended
Date Wed, 12 Jul 2017 21:51:00 GMT

    [ 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

View raw message