Uh oh!
There was an error while loading. Please reload this page.
[fix](load_stream) close brpc stream after load stream is closed - #56120
Conversation
Otherwise, auto partition on multi bes may lead to segment num mismatch problem.
Thearas
commented
Sep 16, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
dataroaring
commented
Sep 16, 2025
run buildall |
PR approved by anyone and no changes requested. |
doris-robot
commented
Sep 16, 2025
TPC-H: Total hot run time: 34484 ms |
doris-robot
commented
Sep 16, 2025
TPC-DS: Total hot run time: 188712 ms |
doris-robot
commented
Sep 16, 2025
ClickBench: Total hot run time: 29.67 s |
dataroaring
commented
Sep 17, 2025
run buildall |
doris-robot
commented
Sep 17, 2025
TPC-H: Total hot run time: 34733 ms |
doris-robot
commented
Sep 17, 2025
TPC-DS: Total hot run time: 188343 ms |
doris-robot
commented
Sep 17, 2025
ClickBench: Total hot run time: 30.2 s |
dataroaring
commented
Sep 17, 2025
run buildall |
hello-stephen
commented
Sep 17, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 17, 2025
FE UT Coverage ReportIncrement line coverage `` 🎉 |
dataroaring
commented
Sep 17, 2025
run buildall |
hello-stephen
commented
Sep 17, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 17, 2025
FE UT Coverage ReportIncrement line coverage `` 🎉 |
dataroaring
commented
Sep 17, 2025
run buildall |
hello-stephen
commented
Sep 17, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
doris-robot
commented
Sep 17, 2025
TPC-H: Total hot run time: 35360 ms |
doris-robot
commented
Sep 17, 2025
TPC-DS: Total hot run time: 189408 ms |
doris-robot
commented
Sep 17, 2025
ClickBench: Total hot run time: 30.37 s |
dataroaring
commented
Sep 17, 2025
run buildall |
Co-authored-by: Xin Liao <liaoxinbit@126.com>
dataroaring
commented
Sep 18, 2025
run buildall |
doris-robot
commented
Sep 18, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
dataroaring
commented
Sep 18, 2025
run buildall |
doris-robot
commented
Sep 18, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 18, 2025
FE UT Coverage ReportIncrement line coverage `` 🎉 |
doris-robot
commented
Sep 18, 2025
TPC-H: Total hot run time: 35157 ms |
doris-robot
commented
Sep 18, 2025
TPC-DS: Total hot run time: 189346 ms |
doris-robot
commented
Sep 18, 2025
ClickBench: Total hot run time: 30.64 s |
hello-stephen
commented
Sep 18, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Sep 18, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Uh oh!
There was an error while loading. Please reload this page.
PR approved by at least one committer and no changes requested. |
…che#56120) pick apache#56120. Otherwise, auto partition on multi bes may lead to segment num mismatch problem. Co-authored-by: Yongqiang YANG <yangyogqiang@selectdb.com> Co-authored-by: Xin Liao <liaoxinbit@126.com>
…65584) Loads that open incremental destinations at runtime, including `INSERT OVERWRITE ... PARTITION(*)`, auto-partition creation, and auto-detect overwrite, could hang forever. On the receiver, `LoadStream` counted `CLOSE_LOAD` messages in `close()` and registered stream IDs for deferred close in a later lock scope, with `_report_result()` network I/O between them. Under concurrent `CLOSE_LOAD`s, the thread that observed `all_closed=true` could drain and clear `_closing_stream_ids` before another already-counted stream registered its ID. The late stream was then never `StreamClose`d: its `on_closed()` callback never fired, the sink remained in `close_wait`, the fragment never reported completion, and the FE latch was never released. This PR introduces `mark_eos_sent_and_collect()`. Deferred registration, the all-received check, and collection of streams to close now run under the same lock. The function is called after the current stream's EOS response write returns, while `brpc::StreamClose()` remains outside the lock. A write-once `_all_close_load_received` latch ensures that a counted-but-late thread observes that all `CLOSE_LOAD`s have arrived and drains its own deferred stream instead of leaving it orphaned. The existing close fence for loads whose sender opened incremental destinations is preserved. The PR adds a BE unit test and a docker regression suite. The inert debug point `LoadStream.close_load.delay_incremental_register` deterministically opens the count-before-register race window: the buggy implementation leaks streams and hangs, while the fixed implementation closes every stream and completes. ### What problem does this PR solve? Issue Number: close#65582 Related PR: #56120 Problem Summary: `INSERT OVERWRITE ... PARTITION(*)` and other loads that open incremental destinations at runtime could hang until `insert_load_default_timeout_second`. The receiver split `CLOSE_LOAD` counting and deferred-close registration across two lock scopes. A thread could therefore contribute to `_close_load_cnt`, pause before registering its stream ID, and resume only after the last-counting thread had already drained and cleared `_closing_stream_ids`. Because no later event would drain the newly registered ID, that BRPC stream remained open permanently and prevented the load from completing. `_closing_stream_ids` was introduced in #56120 to preserve the close fence required by dynamic destinations. This PR keeps that fence but makes registration and the all-received decision atomic under `_lock`, and performs the resulting `StreamClose()` calls outside the critical section. ### Release note Fix a permanent hang of `INSERT OVERWRITE ... PARTITION(*)` and other loads that open incremental destinations at runtime, caused by a receiver-side load-stream close race. --------- Co-authored-by: lizhuoyu5 <lizhuoyu5@jd.com>
…65584) Loads that open incremental destinations at runtime, including `INSERT OVERWRITE ... PARTITION(*)`, auto-partition creation, and auto-detect overwrite, could hang forever. On the receiver, `LoadStream` counted `CLOSE_LOAD` messages in `close()` and registered stream IDs for deferred close in a later lock scope, with `_report_result()` network I/O between them. Under concurrent `CLOSE_LOAD`s, the thread that observed `all_closed=true` could drain and clear `_closing_stream_ids` before another already-counted stream registered its ID. The late stream was then never `StreamClose`d: its `on_closed()` callback never fired, the sink remained in `close_wait`, the fragment never reported completion, and the FE latch was never released. This PR introduces `mark_eos_sent_and_collect()`. Deferred registration, the all-received check, and collection of streams to close now run under the same lock. The function is called after the current stream's EOS response write returns, while `brpc::StreamClose()` remains outside the lock. A write-once `_all_close_load_received` latch ensures that a counted-but-late thread observes that all `CLOSE_LOAD`s have arrived and drains its own deferred stream instead of leaving it orphaned. The existing close fence for loads whose sender opened incremental destinations is preserved. The PR adds a BE unit test and a docker regression suite. The inert debug point `LoadStream.close_load.delay_incremental_register` deterministically opens the count-before-register race window: the buggy implementation leaks streams and hangs, while the fixed implementation closes every stream and completes. ### What problem does this PR solve? Issue Number: close#65582 Related PR: #56120 Problem Summary: `INSERT OVERWRITE ... PARTITION(*)` and other loads that open incremental destinations at runtime could hang until `insert_load_default_timeout_second`. The receiver split `CLOSE_LOAD` counting and deferred-close registration across two lock scopes. A thread could therefore contribute to `_close_load_cnt`, pause before registering its stream ID, and resume only after the last-counting thread had already drained and cleared `_closing_stream_ids`. Because no later event would drain the newly registered ID, that BRPC stream remained open permanently and prevented the load from completing. `_closing_stream_ids` was introduced in #56120 to preserve the close fence required by dynamic destinations. This PR keeps that fence but makes registration and the all-received decision atomic under `_lock`, and performs the resulting `StreamClose()` calls outside the critical section. ### Release note Fix a permanent hang of `INSERT OVERWRITE ... PARTITION(*)` and other loads that open incremental destinations at runtime, caused by a receiver-side load-stream close race. --------- Co-authored-by: lizhuoyu5 <lizhuoyu5@jd.com>
Otherwise, auto partition on multi bes may lead to segment num mismatch problem.
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)