HTTPX PoolTimeout non é un tempo de espera da conexión ao proxy

Identifica a espera no pool de HTTPX e libera as respostas en streaming antes de substituír un proxy que quizais nin recibiu outra petición.

PoolTimeout significa que HTTPX non puido obter unha conexión do pool dentro do tempo de espera configurado. Non demostra que unha nova conexión TCP ao proxy esgotase o tempo. A segunda petición pode seguir agardando dentro do proceso.

É fácil reproducilo se o cliente permite unha conexión e a primeira resposta en streaming queda aberta. Iniciar outra petición non libera esa conexión por arte de maxia.

Deixa clara a responsabilidade pola resposta 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)

Substitúe o enderezo de proxy de documentación antes de executalo. A seguinte petición comeza despois de saír do contexto do stream. Esa saída pecha a resposta aínda que o código abandone o bucle ou lance unha excepción.

Co streaming manual, como client.send(request, stream=True), o teu código é responsable do peche final. Para AsyncClient, a limpeza manual correspondente agárdase con response.aclose(). Pechar unha resposta sen ler libera capacidade, pero pode obrigar a descartar a conexión subxacente en vez de reutilizala.

Le o nome da excepción

ConnectTimeout refírese a establecer a conexión. ReadTimeout refírese a agardar datos de resposta. PoolTimeout refírese a obter unha praza de conexión. Rexistrar só «timeout do proxy» perde a distinción necesaria para escoller a solución.

Revisa respostas abertas, tarefas concorrentes e límites de conexión antes de cambiar as IP dos puntos de conexión. Un pool maior pode ser axeitado para unha carga concorrente lexítima, pero non corrixe respostas que nunca se pechan. Só lle dá á aplicación máis capacidade que ocupar.

Conserva o cliente reutilizable durante toda a carga de traballo. Reconstruílo para que cada petición pareza funcionar pode ocultar un problema de ciclo de vida e perder a reutilización de conexións.

Artigos relacionados