TisonKun commented on issue #9832: [FLINK-11843] Bind lifespan of Dispatcher to leader session URL: https://github.com/apache/flink/pull/9832#issuecomment-541528376 Hi @tillrohrmann, sorry for replying late. What I'm thinking is that 1. Dispatcher-1 scheduled putting job graph in main thread, using JobGraphStore-1. 2. Dispatcher-1 had been revoked leadership, scheduled closing itself in main thread. 3. Dispatcher -2 has been granted leadership, start to serve, using JobGraphStore-2. 4. JobGraphStore-1 put job graph without leadership. When I come to this pull request I think we can defer Dispatcher-2 starts until Dispatcher-1 gracefully shutdown due to we possibly use the same LeaderStore in both JobGraphStore-1 and JobGraphStore-2. But later I notice that it should be a problem when I working on FLINK-10333 and we can prevent unexpected commit without leadership by using different LeaderStore(OneShotLeaderElectionService) per leader epoch. It might be out of this pull request scope though >_< For you information, I agree conceptually one can think that the leadership revocation just happened after the job submission. With FLINK-10333 the persistence of job graph would fail due to it is not the leader. For `waitForTerminatingJobManager`, I wonder isn't it no waiting for "previous JobManager" because we always instance a new `Dispatcher` per leader epoch so that they don't share `jobManagerTerminationFutures`?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
