Skip to content

[regression](cold_heat)add cold heat test for hdfs - #31074

Merged
zhangstar333 merged 5 commits into
apache:masterfrom
lsy3993:lsy_cold_heat_new
Feb 23, 2024
Merged

[regression](cold_heat)add cold heat test for hdfs#31074
zhangstar333 merged 5 commits into
apache:masterfrom
lsy3993:lsy_cold_heat_new

Conversation

@lsy3993

Copy link
Copy Markdown
Contributor

Proposed changes

Issue Number: close #xxx

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

@doris-robot

Copy link
Copy Markdown

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR

@lsy3993

Copy link
Copy Markdown
ContributorAuthor

run buildall

@dataroaring

Copy link
Copy Markdown
Contributor

run buildall

1 similar comment
@lsy3993

Copy link
Copy Markdown
ContributorAuthor

run buildall

@lsy3993

Copy link
Copy Markdown
ContributorAuthor

run buildall

zhangstar333
zhangstar333 previously approved these changes Feb 21, 2024
@github-actionsgithub-actionsBot added the approved Indicates a PR has been approved by one committer. label Feb 21, 2024
@github-actions

Copy link
Copy Markdown
Contributor

PR approved by at least one committer and no changes requested.

@github-actions

Copy link
Copy Markdown
Contributor

PR approved by anyone and no changes requested.

@lsy3993

Copy link
Copy Markdown
ContributorAuthor

run buildall

@github-actionsgithub-actionsBot removed the approved Indicates a PR has been approved by one committer. label Feb 21, 2024
@lsy3993

Copy link
Copy Markdown
ContributorAuthor

run buildall

@github-actionsgithub-actionsBot added the approved Indicates a PR has been approved by one committer. label Feb 23, 2024
@github-actions

Copy link
Copy Markdown
Contributor

PR approved by at least one committer and no changes requested.

@zhangstar333
zhangstar333 merged commit cd7deff into apache:masterFeb 23, 2024
yiguolei pushed a commit that referenced this pull request Feb 23, 2024
HappenLee pushed a commit to HappenLee/incubator-doris that referenced this pull request Apr 24, 2026
morningman added a commit to morningman/doris that referenced this pull request Sep 4, 2026
… and fix 2 muted nonConcurrent cases
## Problem
The NonConcurrent Regression pipeline (build apache#31074) reports one new
failure and six muted cases. Three of the muted ones are stale -- green
for the last 40 runs -- and can simply be unmuted. The other three:
| case | failures / last runs |
|---|---|
| job_p0/streaming_job/test_streaming_job_schedule_task_error | 1 / 60 |
| compaction/test_mow_compact_multi_segments | 39 / 40 |
| query_p0/runtime_filter/rf_bucket_pruning | 90 / 300 |
## Fixes
**FE: a streaming job can wedge in RUNNING with no task**
`StreamingJobSchedulerTask.handlePendingState()` hands the new task to
the scheduler in `createStreamingTask()` and only then writes RUNNING.
By that point the scheduler thread may already have failed the task and
moved the job to PAUSED (`StreamingTaskScheduler.scheduleTasks`), and
the unconditional RUNNING write drops that. Nothing recovers from the
resulting state: `handleRunningState()` never creates a task for a TVF
source -- `processTimeoutTasks()` returns immediately for anything that
is not a `StreamingMultiTblTask` -- and the auto resume handler only
runs while PAUSED. The job then holds a canceled task and a failure
reason while reporting RUNNING, and makes no progress at all. That is
what the build recorded: status RUNNING, canceled task count 2, error
`{"code":"INTERNAL_ERR","msg":"debug point StreamingJob.scheduleTask.exception"}`,
and five minutes of silence.
PENDING -> RUNNING is now a guarded transition
(`StreamingInsertJob.updateJobStatusIfCurrent`), so a status another
thread wrote survives. It also stops a concurrent DROP/STOP JOB from
being revived, which used to raise `IllegalArgumentException`.
**Case: test_mow_compact_multi_segments pinned only the cloud policy**
The suite runs in both deployments but enabled only
`CloudSizeBasedCumulativeCompactionPolicy::pick_input_rowsets.set_input_rowsets`.
On a storage-compute-coupled BE the input rowsets are therefore chosen
by size and score: `[2-2]` alone is 263KB (below
`cumulative_size_based_compaction_lower_size_mbytes`) with score 4
(below `min_cumulative_compaction_num_singleton_deltas`), so the first
compaction is refused with `[E-2000]_input_rowsets is empty`, and the
second one merges `[2-2]` with `[3-3]` into `[2-3]`. Only then, one
rowset short, does `assertTrue(rowsets.size() >= 3)` fire. The local
`SizeBasedCumulativeCompactionPolicy` debug point is now enabled
alongside the cloud one, matching
`fault_injection_p0/test_ordered_compaction_num_seg_rows`.
The two post-compaction segment-count checks also passed
`enableAssert = false`, so the wait loop's timeout exit was silent --
that is what hid the first compaction's failure for two months. They now
assert.
**Case: rf_bucket_pruning did not pin runtime_filter_max_in_num**
`nonConcurrent/conf/fe.conf` sets `use_fuzzy_session_variable=true`, and
one of the four branches in `SessionVariable.initFuzzyModeVariables()`
sets `runtime_filter_max_in_num = 0`. Bucket pruning inverts the IN set
and bails out at `hybrid_set->size() > max_in_num`, which a single-value
filter already satisfies against 0 -- so no bucket is pruned and the
counter stays 0. The suite pinned every other relevant session variable
but this one; its sibling `rf_partition_pruning` has pinned it at 1024
since it was written, for the same reason.
## Testing
- `StreamingInsertJobStatusTransitionTest` (new, 3 cases): the guarded
transition promotes PENDING, and leaves PAUSED and STOPPED alone.
- `test_mow_compact_multi_segments` on a local single FE + single BE
cluster: both compactions now produce a one-segment rowset, all three
rowsets survive, and the closing `delete_bitmap_count == 1` holds --
the part that had never been reached in this deployment.
- `rf_bucket_pruning` with `set global runtime_filter_max_in_num = 0`:
passes with the pin, and without it reproduces the CI failure verbatim
(`single-column HASH distribution should be pruned`, same line).
- `test_streaming_job_schedule_task_error` could not be completed
locally: it loads from S3 and the available credentials are rejected
by the bucket. It needs a CI run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approvedIndicates a PR has been approved by one committer.reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@lsy3993@doris-robot@dataroaring@BiteTheDDDDt@zhangstar333