[jira] [Commented] (DRILL-5547) Drill config options and session options do not work as intended

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DRILL-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16116826#comment-16116826 ] 

ASF GitHub Bot commented on DRILL-5547:
---------------------------------------

Github user dvjyothsna commented on a diff in the pull request:

    https://github.com/apache/drill/pull/868#discussion_r131702178
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/server/options/FallbackOptionManager.java ---
    @@ -144,4 +144,27 @@ public OptionList getOptionList() {
         }
         return list;
       }
    +
    +  public OptionManager getFallback() {
    +    return fallback;
    +  }
    +
    +  /**
    +   * {@link FragmentOptionManager} and {@link SessionOptionManager} use {@link SystemOptionManager} as the fall back
    +   * manager so for both FragmentOptionManager and SessionOptionManager fallback is the SystemOptionManager so it is
    +   * returned. But in case of {@link QueryOptionManager}, it uses {@link SessionOptionManager} as the fallback manager
    +   * and since SessionOptionManager uses SystemOptionManager as fallback, SystemOptionManager can be fetched from the
    +   * SessionOptionManager.
    +   */
    +  public SystemOptionManager getSystemOptionManager() {
    +    final SystemOptionManager systemOptionManager;
    +    if(fallback instanceof SessionOptionManager) {
    --- End diff --
    
    Yes, Correct a System Option Manager is not a fallback for session option manager. FragmentOptionManager and SessionOptionManager use SystemOptionManager as the fall back manager so for both FragmentOptionManager and SessionOptionManager fallback is the System Option Manager so it is returned. But in the case of  QueryOptionManager, it uses Session Option Manager as the fallback manager
     and since Session Option Manager uses System Option Manager as the fallback, we need to go one level deep and fetch System Option Manager from the Session Option Manager.


> 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)