You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fluss.apache.org by "zuston (via GitHub)" <gi...@apache.org> on 2026/07/30 08:59:57 UTC
[PR] [tiering] fail tiering job when readers exceed max duration [fluss]
zuston opened a new pull request, #3810:
URL: https://github.com/apache/fluss/pull/3810
<!--
*Thank you very much for contributing to Fluss - we are happy that you want to help us improve Fluss. To help the community review your contribution in the best possible way, please go through the checklist below, which will get the contribution into a shape in which it can be best reviewed.*
## Contribution Checklist
- Make sure that the pull request corresponds to a [GitHub issue](https://github.com/apache/fluss/issues). Exceptions are made for typos in JavaDoc or documentation files, which need no issue.
- Name the pull request in the format "[component] Title of the pull request", where *[component]* should be replaced by the name of the component being changed. Typically, this corresponds to the component label assigned to the issue (e.g., [kv], [log], [client], [flink], [rust], [python], [c++], [elixir]). Skip *[component]* if you are unsure about which is the best component.
- Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review.
- Make sure that the change passes the automated tests, i.e., `mvn clean verify` passes.
- Each pull request should address only one issue, not mix up code from multiple issues.
- **Generative AI disclosure:** Indicate whether generative AI tools were used in authoring this PR. If yes, specify the tool below.
- [ ] No generative AI tools used
- [ ] Yes (please specify the tool below)
**(The sections below can be removed for hotfixes or typos)**
-->
<!--
Generated-by: [Tool Name and Version] following [the guidelines](https://github.com/apache/fluss/blob/main/AGENTS.md)
-->
### Purpose
<!-- Linking this pull request to the issue -->
Linked issue: close #xxx
<!-- What is the purpose of the change -->
### Brief change log
<!-- Please describe the changes made in this pull request and explain how they address the issue -->
### Tests
<!-- List UT and IT cases to verify this change -->
### API and Format
<!-- Does this change affect API or storage format -->
### Documentation
<!-- Does this change introduce a new feature -->
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [tiering] fail tiering job when readers exceed max duration [fluss]
Posted by "zuston (via GitHub)" <gi...@apache.org>.
zuston commented on PR #3810:
URL: https://github.com/apache/fluss/pull/3810#issuecomment-5203232342
cc @luoyuxia
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [tiering] fail tiering job when readers exceed max duration [fluss]
Posted by "zuston (via GitHub)" <gi...@apache.org>.
zuston commented on PR #3810:
URL: https://github.com/apache/fluss/pull/3810#issuecomment-5311355774
gently ping @luoyuxia
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [tiering] fail tiering job when readers exceed max duration [fluss]
Posted by "luoyuxia (via GitHub)" <gi...@apache.org>.
luoyuxia commented on code in PR #3810:
URL: https://github.com/apache/fluss/pull/3810#discussion_r4109909032
##########
fluss-flink/fluss-flink-common/src/main/java/org/apache/fluss/flink/tiering/source/enumerator/TieringSourceEnumerator.java:
##########
@@ -355,9 +357,45 @@ protected void handleTableTieringReachMaxDuration(
LOG.info("Send {} to reader {}", tieringReachMaxDurationEvent, reader);
context.sendEventToSourceReader(reader, tieringReachMaxDurationEvent);
}
+
+ Duration forceCompleteFinishTimeout =
+ flussConf.get(TIERING_FORCE_COMPLETE_FINISH_TIMEOUT);
+ if (!forceCompleteFinishTimeout.isZero() && !forceCompleteFinishTimeout.isNegative()) {
+ long completionTimeoutThreshold = forceCompleteFinishTimeout.toMillis();
+ timerService.schedule(
+ () ->
+ context.runInCoordinatorThread(
+ () ->
+ failTieringJobIfNotFinished(
+ tablePath,
+ tableId,
+ tieringEpoch,
+ completionTimeoutThreshold)),
+ completionTimeoutThreshold,
+ TimeUnit.MILLISECONDS);
+ }
+ }
+ }
+
+ @VisibleForTesting
+ void failTieringJobIfNotFinished(
+ TablePath tablePath, long tableId, long tieringEpoch, long completionTimeoutThreshold) {
+ Long currentEpoch = tieringTableEpochs.get(tableId);
+ if (currentEpoch != null && currentEpoch.equals(tieringEpoch)) {
Review Comment:
Could we account for an in-progress snapshot before treating an active epoch as a stuck reader? `TieringSplitReader.fetch()` deliberately lets the current snapshot finish after receiving the max-duration event, and only emits its write result after the whole snapshot has been read. `FinishedTieringEvent` is sent by the committer after all bucket results have been committed.
For example, a single-bucket PK table whose initial snapshot takes 12 minutes to scan will now be restarted after about 8 minutes with the defaults (3-minute freshness + 5-minute completion timeout), even if it is continuously making progress. The source does not checkpoint scan progress, and this bucket has no committed lake offset yet, so the next attempt starts the snapshot again. This can leave initial tiering in a restart loop; previously the snapshot was allowed to finish.
Please distinguish snapshot progress/phase before enabling this deadline by default, or keep the watchdog opt-in for now. A regression test with a snapshot that keeps making progress beyond `freshness + timeout` would help ensure it can still complete.
##########
fluss-flink/fluss-flink-common/src/main/java/org/apache/fluss/flink/tiering/source/TieringSourceOptions.java:
##########
@@ -34,4 +34,14 @@ public class TieringSourceOptions {
.defaultValue(Duration.ofSeconds(30))
.withDescription(
"The fixed interval to request tiering table from Fluss cluster, by default 30 seconds.");
+
+ public static final ConfigOption<Duration> TIERING_FORCE_COMPLETE_FINISH_TIMEOUT =
+ key("tiering.force-complete.finish.timeout")
Review Comment:
Could we define this in the tiering service section of `org.apache.fluss.config.ConfigOptions`, alongside `LAKE_TIERING_AUTO_EXPIRE_SNAPSHOT` and `LAKE_TIERING_IO_TMP_DIRS`, and use the key `lake.tiering.force-complete.finish.timeout`? This controls the tiering job's recovery behavior, so grouping it with the existing user-facing tiering service options would make configuration more consistent.
With that prefix, the option should be read from `lakeTieringConfig` and passed through to the enumerator, since `FlussLakeTiering` routes `lake.tiering.*` arguments into that configuration rather than `flussConfig`. Could we also keep the intended default in the option definition instead of declaring zero here and overriding it to five minutes in `FlussLakeTiering.run()`? That would keep the entrypoint and programmatic builder defaults consistent.
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org