AHeise commented on code in PR #152: URL: https://github.com/apache/flink-connector-kafka/pull/152#discussion_r1954110191
########## flink-connector-kafka/src/main/java/org/apache/flink/connector/kafka/sink/internal/Backchannel.java: ########## @@ -0,0 +1,62 @@ +/* + * 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.connector.kafka.sink.internal; + +import org.apache.flink.annotation.VisibleForTesting; + +import java.io.Closeable; +import java.util.function.Consumer; + +/** + * A backchannel for communication between the commiter -> writer. It's used to signal that certain + * transactions have been committed and respective producers are good to be reused. + * + * <p>The model closely follows the idea of statefun except that there is no need to checkpoint the + * state since the backchannel will fully recover on restart from the committer state. + * + * <p>Establishing a backchannel for Kafka sink works because there is only writer and committer and + * nothing in between these two operators. In most cases, these two are chained in live inside the + * same task thread. In rare cases, committer and writer are not chained, so writer and committer + * are in different tasks and threads. However, because of colocations of tasks, we still know that + * both instances will run inside the same JVM and we can establish a backchannel between them. The + * latter case requires some synchronization in the buffer. + * + * <p>Messages can be sent before the backchannel is established. They will be consumed once the + * backchannel is established. + */ +public interface Backchannel<T> extends Closeable { + /** + * Send a message to the other side of the backchannel. Currently, this is the transaction id of + * a committed transaction. + */ + void send(T message); + + /** + * Consume messages from the other side of the backchannel. This is used to signal that certain + * transactions have been committed, so that the writer can recycle the producer. + */ + void consume(Consumer<T> consumer); Review Comment: I guess just relying on poll and looping on call-site is fine. It's a tad more verbose but easier to understand I guess. -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
