HTTPX PoolTimeout ne estas tempolimo de konekto al prokurilo

Identigu atendadon en la konekta stoko de HTTPX kaj liberigu fluajn respondojn antaŭ ol ŝanĝi prokurilon kiu eble ne ricevis alian peton.

PoolTimeout signifas ke HTTPX ne povis ricevi konekton el sia stoko dum la agordita atendotempo. Tio ne pruvas tempoliman malsukceson de nova TCP-konekto al la prokurilo. La dua peto eble ankoraŭ atendas ene de via procezo.

Tio estas facile reproduktebla kiam kliento permesas unu konekton kaj la unua flua respondo restas malfermita. Komenci alian peton ne magie liberigas tiun konekton.

Videbligu la respondecon pri fluaj respondoj

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)

Anstataŭigu la dokumentan prokurilan adreson antaŭ rulado. La sekva peto komenciĝas post eliro el la flua kunteksto. Tiu eliro fermas la respondon eĉ se la kodo rompas la iteracion aŭ levas escepton.

Ĉe mana fluado, ekzemple client.send(request, stream=True), via kodo respondecas pri la fina fermo. Por AsyncClient oni atendas la respondan manan purigon per response.aclose(). Fermi nelegitan respondon liberigas kapaciton sed povas postuli forĵeti la suban konekton anstataŭ reuzi ĝin.

Legu la nomon de la escepto

ConnectTimeout rilatas al starigo de konekto. ReadTimeout rilatas al atendado de respondaj datumoj. PoolTimeout rilatas al akiro de konekta loko. Registri nur «prokurila tempolimo» perdas la distingon necesan por elekti korekton.

Kontrolu malfermitajn respondojn, samtempajn taskojn kaj konektajn limojn antaŭ ŝanĝi finpunktajn IP-ojn. Pli granda stoko povas taŭgi por pravigita samtempa laborŝarĝo, sed ĝi ne korektas respondojn kiuj neniam fermiĝas. Ĝi nur donas al la aplikaĵo pli da kapacito por okupi.

Konservu la klienton reuzebla dum la tuta laborŝarĝo. Rekonstrui klienton por ŝajnigi ĉiun peton funkcianta povas kaŝi vivociklan problemon kaj perdi konektan reuzadon.

Rilataj artikoloj