JNSimba opened a new pull request, #64301:
URL: https://github.com/apache/doris/pull/64301
## Problem
During a from-to streaming job's full (snapshot) sync, a data-skewed table
can produce a single split of 100GB+ that keeps one task busy for well over an
hour. The task timeout is a static `streaming_task_timeout_multiplier *
maxInterval` measured from task start, so such a task is killed and retried in
a loop even though it keeps making steady progress. The only workaround today
is to manually raise `streaming_task_timeout_multiplier`.
## Solution
Make the timeout progress-aware. cdc_client publishes the read-end progress
(`scannedRows`) per running task and exposes it via
`/api/getProgress/{taskId}`. On each scheduling tick the FE pulls it as a
heartbeat: any advance renews the deadline, so a large split that keeps
scanning is never killed. When there is no progress the check falls back to the
original budget, preserving the safety net against an unresponsive task.
- The window is floored by a new `streaming_task_min_timeout_sec` (default
300s), mirroring `routine_load_task_min_timeout_sec`, so a small `maxInterval`
cannot shrink it below the time a task can legitimately make no progress (e.g.
a snapshot split's write tail after the scan finishes).
- Write-side hard failures still surface within seconds via the existing
fail-reason channel, independent of the timeout path.
- The heartbeat state on the FE task is transient and never persisted, so FE
replay is unaffected.
## Test
Unit test `StreamingMultiTblTaskTimeoutTest` covers renew-on-progress,
stalled-within-budget, stalled-over-budget, the min-timeout floor for a small
interval, and the no-progress fallback.
--
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]
