Replace bufferedSubStreamOutput in Http2Demux with direct access to stream state machine
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- scala
- Ambito
- backend, networking
Direzione di ricerca
Inizia tracciando Http2Demux e il relativo percorso bufferedSubStreamOutput, quindi leggi la macchina a stati dello stream e come vengono recuperati e distribuiti i substream. Definisci il comportamento della posizione di attesa, inclusi il buffering dei dati in arrivo anticipati e la gestione di endStream. Il lavoro è completato quando la distribuzione è guidata direttamente dalla disponibilità della macchina a stati e si evita un’infrastruttura di streaming non necessaria per gli stream annullati o completamente ricevuti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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).
- Lingua principale
- Scala
- Stelle
- 196
- Fork
- 56
- Merge medio
- 1g 18h
- PR unite (30g)
- 43
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/pekko-http
-
dependencies
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
apache/pekko-http#1354 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
apache/pekko-http#1273 ·
I maintainer di solito rispondono entro 1 giorno
-
HTTP/2 client ALPN fallback needs a handshake-complete signal that the TLS stage does not emitAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
apache/pekko-http#1249 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
apache/pekko-http#1248 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
apache/pekko-http#1180 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di apache/pekko-http
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
propensive/soundness#2294 ·
I maintainer di solito rispondono entro 1 giorno
-
area:scale audit priority:P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
KD5UJC-XYZ/scarab#231 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
SpinalHDL/VexiiRiscv#198 ·
I maintainer di solito rispondono entro 3 giorni
-
nativeLink relinks every build: IO.write leaves stale trailing bytes in build-checksumForse già presa @kimmoeklund l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
scala-native/scala-native#5111 ·
I maintainer di solito rispondono entro 1 giorno
-
maintenance
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
apex-dev-tools/apex-ls#603 ·
I maintainer di solito rispondono entro 1 giorno