drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bitblender <...@git.apache.org>
Subject [GitHub] drill pull request #921: DRILL-4286 Graceful shutdown of drillbit
Date Wed, 08 Nov 2017 00:35:25 GMT
Github user bitblender commented on a diff in the pull request:

    https://github.com/apache/drill/pull/921#discussion_r149541807
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/server/DrillbitStateManager.java
---
    @@ -0,0 +1,80 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + * http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +
    +package org.apache.drill.exec.server;
    +/*
    +  State manager to manage the state of drillbit.
    + */
    +public class DrillbitStateManager {
    +
    +
    +  public DrillbitStateManager(DrillbitState currentState) {
    +    this.currentState = currentState;
    +  }
    +
    +  public enum DrillbitState {
    +    STARTUP, ONLINE, GRACE, DRAINING, OFFLINE, SHUTDOWN
    +  }
    +
    +  public DrillbitState getState() {
    +    return currentState;
    +  }
    +
    +  private DrillbitState currentState;
    --- End diff --
    
    I think Drillbit.quiescentMode and Drillbit.forceful_shutdown also need NOT be volatile
given the way they are used now. You don't have to enforce happens-before (by preventing re-ordering)
here and even if these variables are volatile, the read of these variables in close() can
anyway race with the setting of these variables in another thread doing a stop/gracefulShutdown.
Let me know if I am missing anything.
    
    That said, adding volatiles can only makes the code more correct (and slower). Since this
code is not critical you can let it be as it is.  


---

Mime
View raw message