StefanRRichter commented on a change in pull request #8322: [FLINK-12364] 
Introduce a CheckpointFailureManager to centralized manage checkpoint failure
URL: https://github.com/apache/flink/pull/8322#discussion_r283250344
 
 

 ##########
 File path: 
flink-runtime/src/main/java/org/apache/flink/runtime/checkpoint/CheckpointFailureManager.java
 ##########
 @@ -0,0 +1,164 @@
+/*
+ * 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.flink.runtime.checkpoint;
+
+import org.apache.flink.util.FlinkRuntimeException;
+
+import java.util.Collections;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.TreeMap;
+
+import static org.apache.flink.util.Preconditions.checkArgument;
+import static org.apache.flink.util.Preconditions.checkNotNull;
+
+/**
+ * The checkpoint failure manager which centralized manage checkpoint failure 
processing logic.
+ */
+public class CheckpointFailureManager {
+
+       private final static int MAXIMUM_TOLERABLE_FAILURE_NUMBER = 
Integer.MAX_VALUE;
+
+       private final static short IGNORE_FLAG = 0;
+       private final static short COUNT_FLAG = 1;
+       private final static short SUCCEED_FLAG = -1;
+
+       private final int tolerableCpFailureNumber;
+       private final FailJobCallback failureCallback;
+       private final TreeMap<Long, Short> serialCheckpointResultTable;
+
+       public CheckpointFailureManager(int tolerableCpFailureNumber, 
FailJobCallback failureCallback) {
+               checkArgument(tolerableCpFailureNumber >= 0
+                               && tolerableCpFailureNumber < 
MAXIMUM_TOLERABLE_FAILURE_NUMBER,
+                       "The tolerable checkpoint failure number is illegal, " +
+                               "it must be greater than or equal to 0 and less 
than " + MAXIMUM_TOLERABLE_FAILURE_NUMBER + ".");
+               this.tolerableCpFailureNumber = tolerableCpFailureNumber;
+               this.failureCallback = checkNotNull(failureCallback);
+               this.serialCheckpointResultTable = new 
TreeMap<>(Collections.reverseOrder());
+       }
+
+       /**
+        * Handle checkpoint exception with a handler callback.
+        *
+        * @param exception the checkpoint exception.
+        */
+       public void handleCheckpointException(CheckpointException exception, 
long checkpointId) {
 
 Review comment:
   @yanghua I just had a quick lock at the implementation of the counting and 
it looks pretty complicated now and I think there is even a bug, e.g. if the 
latest checkpoint completes and clears the map and then an older checkpoint 
that was still ongoing fails it will add to the count. I think that the proper 
counting is maybe something that is a task in itself and in order to move quick 
with this task I suggest that in this step:
   - we implement your initial idea for the simpler counting.
   - but already include the checkpoint id in the reporting so we can later 
refine the counting based on order.
   - we create an issue for that refinement so that it is not forgotten and can 
be discussed.
   Overall, this is an implementation detail that should not stop us from 
progessing fast at this point.
   
   About your problem of getting the checkpoint id in some cases. My thought is 
that we cannot even include it in the exception because some exceptions can 
happen before an id was assigned. However, if it happens in the trigger phase, 
we know that it happend for the very latest checkpoint. If we wanted, we could 
virtually consider such triggers like a checkpoints that fall between ids for 
our order.

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