Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

sdk-http-vertx: response writes ignore Vert.x backpressure

オープン
#614 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java
領域
api, backend

調査の方向性

HttpResponseFlowAdapter.onSubscribe と onNext から始め、次に Vert.x WriteStream の backpressure コントラクトとその Pump ヘルパーを比較します。Response の生成量に上限を設け、writeQueueFull() が true のときは request を一時停止し、drainHandler を通じて再開します。対応する queue の上限については HttpRequestFlowAdapter.handleIncomingBuffer を確認してください。

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

説明

Problem

HttpResponseFlowAdapter in sdk-http-vertx ignores Vert.x's write-side backpressure on the HTTP/2 response stream:

  • onSubscribe pulls unboundedly:
    this.outputSubscription = subscription;
    this.outputSubscription.request(Long.MAX_VALUE);
    
  • onNext writes each slice unconditionally:
    this.httpServerResponse.write(
        Buffer.buffer(Unpooled.wrappedBuffer(slice.asReadOnlyByteBuffer())));
    
    No check on HttpServerResponse.writeQueueFull(), no drainHandler(...) to resume.

The Reactive-Streams contract and Vert.x's own WriteStream docs both expect callers to throttle production when writeQueueFull() returns true. The adapter throws away that signal.

Observed evidence

While investigating a separate e2e issue, instrumentation on the SDK side recorded writeQueueFull=true on the very first response writes under a 50-concurrent ctx.run × 10×64 KiB workload (Restate runtime as the peer). That confirms the writeQueue does cross Vert.x's high-watermark threshold in realistic Restate workloads — the adapter just keeps writing past it.

(We did not observe SDK-side heap growth or autoRead toggling in that test, so this issue is a code-correctness / future-proofing fix rather than the cause of the failure we were chasing.)

Proposal

Apply standard Reactive-Streams + Vert.x backpressure to HttpResponseFlowAdapter:

  • Replace request(Long.MAX_VALUE) with a bounded initial request (e.g. request(N)).
  • In onNext, after writing, check httpServerResponse.writeQueueFull():
    • If full, do not call subscription.request(...); instead install httpServerResponse.drainHandler(v -> subscription.request(M)) to resume.
    • If not full, request the next batch immediately.
  • This is the same pattern Vert.x's own Pump helper implements.

Companion (lower priority, same class of bug)

The request side has an analogous unbounded enqueue: HttpRequestFlowAdapter.handleIncomingBuffer pushes incoming buffers into an ArrayDeque<ByteBuffer> without an upper bound. Worth bounding while we're in the same module.

Files

  • sdk-http-vertx/src/main/java/dev/restate/sdk/http/vertx/HttpResponseFlowAdapter.java
  • sdk-http-vertx/src/main/java/dev/restate/sdk/http/vertx/HttpRequestFlowAdapter.java (companion)
主要言語
Java
スター
60
フォーク
17
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

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

restatedev/sdk-java のほかの issue

restatedev/sdk-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

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

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