Hindi proxy connection timeout ang HTTPX PoolTimeout

Ibig sabihin ng PoolTimeout ay hindi nakakuha ang HTTPX ng koneksyon sa pool sa loob ng itinakdang oras ng paghihintay. Hindi ito patunay na nag-timeout ang bagong TCP connection sa proxy. Baka naghihintay pa ang pangalawang request sa loob ng process mo.

Madaling ulitin ito kung isang koneksyon lang ang pinapayagan ng client at naiwang bukas ang unang streaming response. Hindi kusang napapalaya ang koneksyong iyon sa pagsisimula ng isa pang request.

Linawin kung sino ang may pananagutan sa streaming response

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)

Palitan ang proxy address na pangdokumentasyon bago patakbuhin. Magsisimula ang susunod na request pagkatapos lumabas sa stream context. Isinasara ng paglabas na iyon ang response kahit lumabas ang code sa loop o mag-raise ng exception.

Sa manual streaming, tulad ng client.send(request, stream=True), responsibilidad ng code mo ang huling pagsara. Para sa AsyncClient, ina-await ang katumbas na manual cleanup gamit ang response.aclose(). Ang pagsara sa hindi pa nababasang response ay nagpapalaya ng kapasidad, pero baka kailangang itapon ang pinagbabatayang koneksyon sa halip na gamitin muli.

Basahin ang pangalan ng exception

Tungkol sa pagtatatag ng koneksyon ang ConnectTimeout. Tungkol sa paghihintay ng response data ang ReadTimeout. Tungkol sa pagkuha ng connection slot ang PoolTimeout. Nawawala ang pagkakaibang kailangan sa pagpili ng solusyon kung «proxy timeout» lang ang ila-log.

Suriin ang bukas na response, sabay-sabay na task, at connection limit bago magpalit ng endpoint IP. Maaaring tama ang mas malaking pool para sa makatwirang sabay-sabay na load, pero hindi nito naaayos ang mga response na hindi kailanman isinasara. Dinadagdagan lang nito ang kapasidad na maaaring sakupin ng app.

Panatilihing magagamit muli ang client sa buong workload. Ang paggawa muli nito para magmukhang gumagana ang bawat request ay maaaring magtago ng lifecycle problem at magsayang ng connection reuse.