Skip to content

branch-4.1: [fix](cloud) set recycler S3 client requestTimeoutMs to avoid curl-28 on slow DeleteObjects (mirror #49315) #64758#65804

Open
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-64758-branch-4.1
Open

branch-4.1: [fix](cloud) set recycler S3 client requestTimeoutMs to avoid curl-28 on slow DeleteObjects (mirror #49315) #64758#65804
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-64758-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #64758

… on slow DeleteObjects (mirror #49315) (#64758)

## Proposed changes

The cloud recycler builds its S3 client in `S3Accessor::init()`
(`cloud/src/recycler/s3_accessor.cpp`) from an
`Aws::Client::ClientConfiguration` that never sets `requestTimeoutMs`,
so
it keeps the SDK default of 3000ms. The vendored aws-sdk-cpp maps that
to
`CURLOPT_LOW_SPEED_TIME=3` / `CURLOPT_LOW_SPEED_LIMIT=1`, so any slow or
large `DeleteObjects` request that can't sustain >1 byte/s for 3 seconds
is aborted with curl error 28 ("Timeout was reached").

This is the same defect that #49315 fixed for the BE
(`be/src/util/s3_util.cpp`, `requestTimeoutMs = 30000`), but the cloud
recycler's client was missed by that change. On object stores with
higher per-request latency (e.g. an OVH cold object-storage vault) the
recycler wedges: every `delete_rowset_data` / `DeleteObjects` aborts at
3s with curlCode 28, the recycler burns its delete budget on timed-out
ops, and the orphan backlog never drains.

This change sets `requestTimeoutMs = 30000` and
`connectTimeoutMs = 5000` on the recycler client, mirroring #49315.

Symptom in MS recycler log before the fix:
```
s3_obj_client.cpp: failed to delete objects ... responseCode=-1 error="curlCode: 28, Timeout was reached"
recycler.cpp: failed to delete rowset data, instance_id=...
```

## Further comments

Pure timeout-config change in the recycler S3 client path; no behavior
change for fast object stores. `MaxDeleteBatch` is left unchanged.

Signed-off-by: Steven Pall <mail@stevenpall.ca>
@github-actions
github-actions Bot requested a review from yiguolei as a code owner July 20, 2026 06:33
@hello-stephen

Copy link
Copy Markdown
Contributor

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

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants