HTTPX PoolTimeout n’est pas un délai de connexion au proxy

Identifiez l’attente du pool HTTPX et libérez les réponses en streaming avant de remplacer un proxy qui n’a peut-être jamais reçu la requête suivante.

PoolTimeout signifie qu’HTTPX n’a pas pu obtenir de connexion dans son pool pendant le délai d’attente configuré. Ce n’est pas la preuve qu’une nouvelle connexion TCP au proxy a expiré. La deuxième requête attend peut-être encore dans votre processus.

Ce cas se reproduit facilement si le client n’autorise qu’une connexion et que la première réponse en streaming reste ouverte. Lancer une autre requête ne libère pas cette connexion par magie.

Rendre explicite la responsabilité des réponses en 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)

Remplacez l’adresse de proxy de documentation avant l’exécution. La requête suivante commence après la sortie du contexte de streaming. Cette sortie ferme la réponse même si le code quitte la boucle ou lève une exception.

Avec un streaming manuel, comme client.send(request, stream=True), votre code est responsable de la fermeture finale. Pour AsyncClient, le nettoyage manuel correspondant s’attend avec response.aclose(). Fermer une réponse non lue libère de la capacité, mais peut obliger à abandonner la connexion sous-jacente plutôt qu’à la réutiliser.

Lire le nom de l’exception

ConnectTimeout concerne l’établissement de la connexion. ReadTimeout concerne l’attente de données de réponse. PoolTimeout concerne l’obtention d’une place de connexion. Un simple journal « délai proxy dépassé » perd la distinction nécessaire pour choisir une correction.

Examinez les réponses ouvertes, les tâches concurrentes et les limites de connexion avant de changer d’IP. Un pool plus grand peut convenir à une charge concurrente légitime, mais ne corrige pas des réponses jamais fermées. Il donne seulement davantage de capacité à occuper.

Gardez le client réutilisable sur toute la charge de travail. Recréer un client pour donner l’impression que chaque requête fonctionne peut masquer un problème de cycle de vie et perdre la réutilisation des connexions.

Articles similaires