Zakelly opened a new pull request, #26682:
URL: https://github.com/apache/flink/pull/26682

   ## What is the purpose of the change
   
   This PR addresses the generalization of the asynchronous processing 
framework initially designed for the Disaggregated State Management (FLIP-425). 
While the original implementation focused on key-ordered state operations, we 
identified a broader requirement to support other asynchronous scenarios, such 
as the key-ordered async lookup proposed in FLIP-519. This generalization was 
discussed and validated in the Apache Flink community mailing list 
[here](https://lists.apache.org/thread/z3th724l6vnylgv601gvcbdy4oy2wy7r). The 
primary objective is to decouple the asynchronous execution logic from 
state-specific dependencies, enabling reuse across diverse use cases while 
maintaining compatibility with existing stateful operators.
   
   ## Brief change log
   
   This change is a code refactoring effort to abstract the framework from 
state-centric design to a generic asynchronous processing model. The original 
framework tightly coupled async logic with state management, resulting in class 
names and interfaces (e.g., StateFuture) that were not extensible to non-state 
scenarios. The refactoring includes following parts (corresponding to each 
commit):
   
   - Generalize the AsyncExecutionController and futures 
   - Generalize the async state processing related operator
   - Extract the processNonRecord in async operators for override
   - Parameterize Epoch option in constructor
   - Introduce AbstractAsyncRunnableStreamOperator for non-keyed processing
   
   ## Verifying this change
   
   This change is already covered by existing tests. The original state 
processing UT and IT cases should cover current implementation.
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): no
     - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`: no
     - The serializers: no
     - The runtime per-record code paths (performance sensitive): yes
     - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
     - The S3 file system connector: no
   
   ## Documentation
   
     - Does this pull request introduce a new feature? no
     - If yes, how is the feature documented? not applicable
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to