Feature Request: Tracking # of HTTP requests made on the current TCP connection
Nessuno ha ancora preso questa issue.
- Lingua principale
- Ruby
- Stelle
- 148
- Fork
- 95
- Merge medio
- 10h 54m
- PR unite (30g)
- 4
Descrizione
For persistent connections, some servers are configured to reset them after a certain number of HTTP requests. Net::HTTP::Persistent added a max_requests variable to preemptively close your connection after a certain amount of HTTP requests are made for this reason in https://github.com/drbrain/net-http-persistent/pull/42
However, without changes to Net::HTTP, Net::HTTP::Persistent can only track how many times it makes a request of it's Net::HTTP instance. But this isn't perfect: begin_transport can re-connect on a new TCP connection if it finds the socket was closed some time after the last time you used it, like if the server closed the connection, and Net::HTTP::Persistent will never know there's a new TCP connection, and that it should therefor reset its count of requests over the TCP connection back to 0.
My suggestion is that we make an instance variable here in Net::HTTP called @num_requests_on_connection, that gets set to 0 at the end of connect, and is incremented at the end of begin_transport after the reconnection attempts. I believe that way we could get an accurate count!
@raggi @drbrain
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
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.
Direzione di ricerca
Inizia in lib/net/http.rb, nei punti referenziati connect e begin_transport, e segui come vengono stabilite e riutilizzate le connessioni persistenti. Verifica che il contatore delle richieste venga reimpostato quando viene creata una connessione TCP e incrementato dopo i tentativi di trasporto, in modo che i chiamanti possano osservare correttamente le richieste effettuate sulla connessione corrente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- ruby
- Ambito
- api, networking
- Tipo di issue
- Funzionalità
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Ferma
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 45/100