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

Replace bufferedSubStreamOutput in Http2Demux with direct access to stream state machine

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
scala

調査の方向性

まず Http2Demux とその bufferedSubStreamOutput パスを追跡し、次にストリームの状態機械と、サブストリームがどのように取り出されてディスパッチされるかを読みます。早期に到着するデータのバッファリングと endStream の処理を含め、保持位置の動作を定義します。完了条件は、ディスパッチが状態機械の直接的な準備状態によって駆動され、キャンセルされたストリームや完全に受信済みのストリームに対する不要なストリーミング基盤を回避することです。

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

説明

enhancement performance

Right now, we dispatch substreams as soon as they are incoming / we detect them into bufferedSubStreamOutput. Instead, we can let them be pulled and query the state machine whether a stream is ready to be dispatched. In particular, this will automatically avoid allocating infrastructure for streams that might never materialize (e.g. because they are cancelled before they will be pulled).

One way to do it would be to introduce a kind of "holding position" state. In that state, we could also already start collecting incoming data (which we have to buffer anyway up to the default window size). In the best case, we have already seen endStream = true for the request side, so that we can avoid setting up the expensive streaming infrastructure (this will mean that in overload cases we will "automatically" reduce work because we collect buffers early on when there is backpressure from the stream handling flow).

主要言語
Scala
スター
196
フォーク
56
平均マージ
1日 18時間
マージ済み PR(30日)
43

環境構築

はじめの一歩

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

apache/pekko-http のほかの issue

apache/pekko-http の issue をすべて見る

似ている issue

Scala の issue をもっと見る

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

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