Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

BlazeClient's idleTimeout works differently than BlazeServer's idleTimeout

Aperta
#635 10 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
scala

Direzione di ricerca

Inizia confrontando la gestione di idleTimeout in BlazeClient e BlazeServer, inclusa la loro IdleTimeoutStage condivisa, quindi esamina come vengono gestite le connessioni inutilizzate nel pool di connessioni del client. Il lavoro è completo quando la semantica di timeout prevista è coerente e il pool dispone di un meccanismo definito per rimuovere le connessioni inutilizzate, con test che coprono entrambi i comportamenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement module:blaze-client module:blaze-server

Both BlazeClient and BlazeServer offer an idleTimeout configuration option. The option has the same name in both, and shares implementation (IdleTimeoutStage) but from user's perspective it behaves differently.

In BlazeClient the idleTimeout is active only when a request is in-flight. It may kick in if the server takes too long to respond (unless other timeout does it first) or when the server starts sending a response and then pauses for too long. An idle (not borrowed from the pool) connection will remain open indefinitly as the idleTimeout is deactivated when a connection is returned to the pool. This may contradict users assumptions about the meaning of the word "idle" in the context of an HTTP client.

In BlazeServer the idleTimeout is always active, and it may terminate connections that have an in-flight request but nothing happened for too long, as well as connections which are kept open but unused.

I see this inconsistency as a bad developer experience. In addition to that I see the lack of mechanism for evicting unused connections from the client's connection pool, as a missing feature and potential resource leak.

Lingua principale
Scala
Stelle
371
Fork
63
Merge medio
1g 18h
PR unite (30g)
8

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di http4s/blaze

Tutte le issue di http4s/blaze

Issue simili

Altre issue su Scala

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.