Add jitter to the commit retry backoff in `Transaction::commit`

オープン 初心者向け
  • 何か問題がありますか？
#3,348 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
databases

調査の方向性

Transaction::build_backoff（crates/iceberg/src 配下で grep）から始め、commit.retry.* プロパティのセマンティクスを変更せずに backon::ExponentialBuilder にジッターを追加する。backon のデフォルトのジッターと、Java の最大 10% までの上限付きジッターのどちらかを選択し、その後、既存のコミットリトライテスト（CatalogCommitConflicts や commit_num_retries に言及しているもの）を見て、遅延がどのようにアサートされているかを確認する。cargo test が通り、リトライが同一間隔で発火しなくなったことが実証できれば完了。ただし、報告者が自分で PR を提出すると提案しているため、まず担当を確認すること。

索引モデルが issue の本文から書いたものです。

説明

Is your feature request related to a problem or challenge?

Transaction::commit retries retryable errors (such as CatalogCommitConflicts from a REST 409) with exponential backoff built in Transaction::build_backoff:

ExponentialBuilder::new()
    .with_min_delay(Duration::from_millis(props.commit_min_retry_wait_ms()?))
    .with_max_delay(Duration::from_millis(props.commit_max_retry_wait_ms()?))
    .with_total_delay(Some(Duration::from_millis(props.commit_total_retry_timeout_ms()?)))
    .with_max_times(props.commit_num_retries()?)
    .with_factor(2.0)
    .build()

The backoff has no jitter, so every writer waits the same 100 ms, 200 ms, 400 ms, … after a conflict. When several processes append to the same table and conflict on the same commit, they retry in lockstep. Each round lets one writer through and sends the rest into the next round together, so contended writers use up commit.retry.num-retries faster than they would with retries spread out, and the catalog gets bursts of load_table + update_table requests.

We hit this while building an append-only streaming sink where many instances write to one table: in a test with 8 concurrent appenders on the memory catalog, every run had commits that lost to another writer and were retried.

The Java implementation adds jitter to commit retries (Tasks.exponentialBackoff adds a random 0–10% of the delay), so writers from different engines also behave differently on the same table today.

Describe the solution you'd like

Enable jitter in build_backoff, e.g. .with_jitter() on the backon::ExponentialBuilder. It's a one-line change, and the existing commit.retry.* properties keep their meaning.

If matching Java's bounded jitter (up to 10% on top of the delay) is preferred over backon's default jitter, that would also work. The main point is that concurrent writers shouldn't retry at exactly the same moments.

Willingness to contribute

I can contribute a PR for this, including a test.

主要言語
Rust
スター
1.4k
フォーク
618
平均マージ
3日 22時間
マージ済み PR（30日）
72

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/iceberg-rust のほかの issue

apache/iceberg-rust の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。