Github user EronWright commented on the issue:

    https://github.com/apache/flink/pull/5427
  
    @StephanEwen thanks for taking a look, I agree with trying to avoid a new 
lifecycle method.
    
    The `initializeState` method on the hook interface gives the hook an 
unconditional initialization point. 
    In the Pravega case, we would move reader-group (RG) initialization from 
client to server, and always reset the RG to its initial conditions.   A 
subsequent restore may or may not occur.
    
    Assuming we like this approach, let's discuss how to make it work purely 
with `restoreLatestCheckpointedState`.   The `restoreLatestCheckpointedState` 
method is not called by the ExecutionGraph (EG) upon initial execution, which 
we would want to support the new `initializeState` method.   Would there be any 
issue with calling `restoreLatestCheckpointedState` on initial execution? Such 
symmetry would seem desirable.  
    
    **Existing approach**:
    ```
    === initial ===
    \-- JM.submitJob
    |   \-- EG.scheduleForExecution
    
    === restart===
    \-- RestartCallback.triggerFullRecovery
    |   \-- EG.restart
    |   |   \-- CC.restoreLatestCheckpointedState
    |   |   \-- EG.scheduleForExecution
    ```
    
    **Suggested approach**:
    ```
    === initial ===
    \-- JM.submitJob
    |   \-- EG.start  (** new method **)
    |   |   \-- CC.restoreLatestCheckpointedState
    |   |   |   \-- Hook.initializeState
    |   |   \-- EG.scheduleForExecution
    
    === restart===
    \-- RestartCallback.triggerFullRecovery
    |   \-- EG.restart
    |   |   \-- CC.restoreLatestCheckpointedState
    |   |   |   \-- Hook.initializeState
    |   |   \-- EG.scheduleForExecution
    ```


---

Reply via email to