HTTPX PoolTimeout non è un timeout di connessione al proxy

Riconosci l’attesa del pool HTTPX e libera le risposte in streaming prima di sostituire un proxy che potrebbe non aver ricevuto un’altra richiesta.

PoolTimeout significa che HTTPX non è riuscito a ottenere una connessione dal pool entro il tempo di attesa configurato. Non dimostra che una nuova connessione TCP al proxy sia scaduta. La seconda richiesta potrebbe ancora attendere nel tuo processo.

È facile riprodurlo quando il client consente una sola connessione e la prima risposta in streaming resta aperta. Avviare un’altra richiesta non libera magicamente quella connessione.

Rendi chiaro chi gestisce la risposta in streaming

import httpx

limits = httpx.Limits(
    max_connections=1,
    max_keepalive_connections=1,
)
timeout = httpx.Timeout(
    connect=5, read=10, write=10, pool=1
)

with httpx.Client(
    proxy="http://203.0.113.10:8080",
    trust_env=False,
    limits=limits,
    timeout=timeout,
) as client:
    with client.stream("GET", "https://example.com/") as response:
        print(response.status_code)
        for chunk in response.iter_bytes():
            print(len(chunk))

    next_response = client.get("https://example.com/")
    print(next_response.status_code)

Sostituisci l’indirizzo di proxy di documentazione prima dell’esecuzione. La richiesta successiva inizia dopo l’uscita dal contesto dello stream. Tale uscita chiude la risposta anche se il codice interrompe il ciclo o solleva un’eccezione.

Con streaming manuale, come client.send(request, stream=True), il tuo codice è responsabile della chiusura finale. Per AsyncClient, la corrispondente pulizia manuale si attende con response.aclose(). Chiudere una risposta non letta libera capacità, ma può richiedere di scartare la connessione sottostante invece di riutilizzarla.

Leggi il nome dell’eccezione

ConnectTimeout riguarda l’apertura della connessione. ReadTimeout riguarda l’attesa dei dati di risposta. PoolTimeout riguarda l’ottenimento di uno slot di connessione. Registrare soltanto «timeout del proxy» perde la distinzione necessaria a scegliere la correzione.

Controlla risposte aperte, attività concorrenti e limiti di connessione prima di cambiare gli IP degli endpoint. Un pool più ampio può essere appropriato per un carico concorrente legittimo, ma non corregge risposte mai chiuse. Offre soltanto più capacità da occupare.

Mantieni il client riutilizzabile per tutto il carico di lavoro. Ricrearlo per far sembrare funzionante ogni richiesta può nascondere un problema di ciclo di vita e rinunciare al riutilizzo delle connessioni.

Articoli correlati