zentol commented on code in PR #22670: URL: https://github.com/apache/flink/pull/22670#discussion_r1246703015
########## flink-runtime/src/main/java/org/apache/flink/runtime/sink/coordinator/SinkCoordinator.java: ########## @@ -0,0 +1,158 @@ +/* + * 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.sink.coordinator; + +import org.apache.flink.annotation.Internal; +import org.apache.flink.annotation.VisibleForTesting; +import org.apache.flink.runtime.jobgraph.OperatorID; +import org.apache.flink.runtime.operators.coordination.CoordinatorStore; +import org.apache.flink.runtime.operators.coordination.OperatorCoordinator; +import org.apache.flink.runtime.operators.coordination.OperatorEvent; + +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import javax.annotation.Nullable; + +import java.io.ByteArrayInputStream; +import java.io.ByteArrayOutputStream; +import java.io.ObjectInputStream; +import java.io.ObjectOutputStream; +import java.util.concurrent.CompletableFuture; + +/** + * The default implementation of the {@link OperatorCoordinator} for the {@link + * org.apache.flink.api.connector.sink2.Sink}. + * + * <p>The <code>SinkCoordinator</code> helps trigger an immediate global checkpoint when all sink + * operators are reaching end of data. + */ +@Internal +public class SinkCoordinator implements OperatorCoordinator { Review Comment: > For example, given that FINISHING effectively belongs to what is currently RUNNING, we would need to go through all existing references of ExecutionState#RUNNING (47+ references) and check if we need to specify ExecutionState#FINISHING there. This would introduce more complexity and potentially make the PR error-prone. In practice you should've already needed to do that. FLIP-147 effectively introduced a separate execution state but no part of the coordination layer is aware of it. How do you know that no part of the system is doing something that shouldn't happen after the task started to wait for the checkpoint? If we just closed our eyes and assumed there to not be a problem, well then that is quite a red flag. As an example, it would be beneficial for the adaptive scheduler to not scale up the job when some tasks (or some percentage of them) are waiting for a checkpoint, or delay manual scale-down operations. It would also allow us to communicate to users why a task isn't shutting down, even though it caught up with the input and is neither consuming nor producing any data. It would make it trivial to capture how much time operators spend idling waiting for that next checkpoint, because we could re-use our setup for the deployment time. Whether something is "easier to implement" doesn't really matter. What matters is whether the end result is maintainable and easy to understand. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
