luoyuxia commented on code in PR #3683:
URL: https://github.com/apache/fluss/pull/3683#discussion_r3607983562
##########
fluss-flink/fluss-flink-tiering/src/main/java/org/apache/fluss/flink/tiering/FlussLakeTiering.java:
##########
@@ -96,6 +97,13 @@ public FlussLakeTiering(String[] args) {
org.apache.flink.configuration.Configuration flinkConfig =
new org.apache.flink.configuration.Configuration();
flinkConfig.set(JobManagerOptions.EXECUTION_FAILOVER_STRATEGY,
FULL_RESTART_STRATEGY_NAME);
+ // Configure restart strategy: the tiering job is completely stateless
(offsets are
+ // persisted in Fluss Server's LakeSnapshot, not in Flink checkpoint
state), so it is
+ // safe to restart indefinitely on failure. Without this, Flink
defaults to "no-restart"
+ // when checkpoint is not enabled, causing the job to fail permanently
on any exception.
+ flinkConfig.set(RestartStrategyOptions.RESTART_STRATEGY,
"fixed-delay");
Review Comment:
Before this change, the failover test enabled checkpointing and therefore
inherited Flink 1.20’s default exponential-delay restart policy (1s initial
backoff, 1.5 multiplier, and 1min maximum backoff). Selecting fixed-delay here
changes the behavior to retry every 1s indefinitely. During a persistent
lake/storage failure, this can continuously hit the external system and flood
logs instead of backing off. Is this fixed retry cadence intentional? If the
goal is to retain the retry behavior previously exercised by the
checkpoint-enabled test while enabling restarts without checkpoints, could we
explicitly select `exponential-delay` instead (whose default attempt count is
effectively infinite), or otherwise document and explicitly configure the
fixed-delay policy?
--
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]
