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)