Discussion thread | https://lists.apache.org/thread/b8f509878ptwl3kmmgg95tv8sb1j5987 |
---|---|
Vote thread | |
JIRA |
|
Release | <Flink Version> |
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
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, flink-connector-mongodb and soon.
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.
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); }
As shown in FLINK-31324, FLINK-28853 used to change the default constructor of SingleThreadFetcherManager.However, it influenced a lot. Finally, the former constructor was added back and marked asDeprecated。
Therefore, why not make SingleThreadFetcherManager and FutureCompletingBlockingQueue PublicEvolving?
Public Interfaces
Change SingleThreadFetcherManager
, FutureCompletingBlockingQueue
and parent class SplitFetcherManager
from Internal
to PublicEvolving
.
Proposed Changes
nothing else to do.
Compatibility, Deprecation, and Migration Plan
Any change to SingleThreadFetcherManager
, FutureCompletingBlockingQueue
and parent class SplitFetcherManager
later will be careful for compatility.
Test Plan
nothing else to do.