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)

Reply via email to