Hongshun Wang created FLINK-33465: ------------------------------------- Summary: Make SingleThreadFetcherManager and FutureCompletingBlockingQueue as PublicEvolving. Key: FLINK-33465 URL: https://issues.apache.org/jira/browse/FLINK-33465 Project: Flink Issue Type: Improvement Components: Connectors / Parent Affects Versions: 1.18.0 Reporter: Hongshun Wang Fix For: 1.19.0
As discussed in FLINK-31324, though the {{SingleThreadFetcherManager}} is annotated as {{{}Internal{}}}, it actually acts as some-degree public API, which is widely used in many connector projects: [flink-cdc-connector|https://github.com/ververica/flink-cdc-connectors/blob/release-2.3.0/flink-connector-mysql-cdc/src/main/java/com/ververica/cdc/connectors/mysql/source/reader/MySqlSourceReader.java#L93], [flink-connector-mongodb|https://github.com/apache/flink-connector-mongodb/blob/main/flink-connector-mongodb/src/main/java/org/apache/flink/connector/mongodb/source/reader/MongoSourceReader.java#L58] and so on. More over, even the constructor of `SingleThreadMultiplexSourceReaderBase` (which is PublicEvolving) includes the params of `SingleThreadFetcherManager` and `FutureCompletingBlockingQueue` .That means that the `SingleThreadFetcherManager` and `FutureCompletingBlockingQueue`have already been exposed to users for a long time and are widely used. ```java public SingleThreadMultiplexSourceReaderBase( FutureCompletingBlockingQueue<RecordsWithSplitIds<E>> elementsQueue, SingleThreadFetcherManager<E, SplitT> splitFetcherManager, RecordEmitter<E, T, SplitStateT> recordEmitter, Configuration config, SourceReaderContext context) { super(elementsQueue, splitFetcherManager, recordEmitter, config, context); } ``` Thus, why not make SingleThreadFetcherManager and FutureCompletingBlockingQueue PublicEvolving? -- This message was sent by Atlassian Jira (v8.20.10#820010)