Guosmilesmile opened a new pull request, #15151: URL: https://github.com/apache/iceberg/pull/15151
This PR is a continuation of https://github.com/apache/iceberg/pull/15042. In this approach, the lock is maintained inside `TriggerManagerOperator`, and `TableMaintenanceCoordinator` acts as a bridge. It holds a reference to `TriggerManagerOperator` in a static map, and uses that to receive events from `LockRemoverOperator` and release the lock held by `TriggerManagerOperator`. Normal flow 1. `TriggerManagerOperator` decides whether to fire a trigger and, if so, acquires the lock internally and sends the trigger downstream. 2. After the task is finished, the trigger or the watermark reaches `LockRemoverOperator`. 3. `LockRemoverOperator` sends an event to `TableMaintenanceCoordinator`. `TableMaintenanceCoordinator` uses the reference stored in its static map to find the corresponding `TriggerManagerOperator` and sends a “release lock” event to it. 4. `TriggerManagerOperator` releases the lock. Recovery flow 1. During `initializeState`, `TriggerManagerOperator` marks itself as “in recovery” and then sends a recovery trigger downstream. While the “in recovery” flag is true, other tasks are not allowed to operate on it. 2. When the recovery trigger or the watermark reaches `LockRemoverOperator`, it sends an event to `TableMaintenanceCoordinator` to release the lock. 3. `TriggerManagerOperator` releases the lock. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
