rkhachatryan commented on a change in pull request #10151: [FLINK-14231] Handle 
the processing-time timers when closing operators to make endInput semantics on 
the operator chain strict
URL: https://github.com/apache/flink/pull/10151#discussion_r355403389
 
 

 ##########
 File path: 
flink-streaming-java/src/main/java/org/apache/flink/streaming/runtime/tasks/ProcessingTimeServiceImpl.java
 ##########
 @@ -39,11 +78,282 @@ public long getCurrentProcessingTime() {
 
        @Override
        public ScheduledFuture<?> registerTimer(long timestamp, 
ProcessingTimeCallback target) {
-               return timerService.registerTimer(timestamp, 
processingTimeCallbackWrapper.apply(target));
+               if (isQuiesced()) {
+                       return new NeverCompleteFuture(
+                               
ProcessingTimeServiceUtil.getProcessingTimeDelay(timestamp, 
getCurrentProcessingTime()));
+               }
+
+               final TimerScheduledFuture<?> timer = new 
TimerScheduledFuture<Void>(false, this::removeUndoneTimer);
+               undoneTimers.put(timer, Boolean.TRUE);
+
+               // double check to deal with the following race conditions:
+               // 1. canceling timers from the undone table occurs before 
putting this timer into the undone table
+               //    (see #cancelTimersNotInExecuting())
+               // 2. using the size of the undone table to determine if all 
timers have done occurs before putting
+               //    this timer into the undone table (see 
#tryCompleteTimersDoneFutureIfQuiesced())
+               if (isQuiesced()) {
+                       removeUndoneTimer(timer);
+                       return new NeverCompleteFuture(
+                               
ProcessingTimeServiceUtil.getProcessingTimeDelay(timestamp, 
getCurrentProcessingTime()));
+               }
+
+               timer.bind(timerService.registerTimer(timestamp, 
timer.getCallback(processingTimeCallbackWrapper.apply(target))));
 
 Review comment:
   As I understand it, the purpose of splitting the creation of `timer` and 
call to `timer.bind` is not to 
   call `timerService.registerTimer` if `ProcessingTimeServiceImpl` was 
quiesced in between, right?
   But it can be also be quiesced right after we call 
`timerService.registerTimer`.
   
   So it seems unnecessary but complicates TimerScheduledFuture internally.

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

Reply via email to