Malvarmigoj en proksea baseno: spuri fiaskojn kaj testi reakiron

Prokso maltrafas unu limdaton. La baseno forigas ĝin. Post horo la prokso denove sanas, sed via aplikaĵo ne havas manieron malkovri tion, ĉar ĝi forĵetis la rikordon.

Forigo povas taŭgi por revokita konto aŭ por finpunkto, kiun la operatoro retiris. Pasema fiasko meritas alian staton.

Konservu sufiĉan historion por la sekva decido

Taŭga

Disponebla por ordinara laboro laŭ la nuna politiko.

Malvarmiĝas

Provizore retenita ĝis registrita limdato.

Provo permesata

Unu kontrolita provo povas taksi reakiron.

Malŝaltita

Operatoro aŭ daŭra kondiĉo forigis ĝin el la servo.

Konservu la kialon kaj la stadion kune kun la transiro. Rifuzo de konekto, rifuzitaj legitimiloj, malrapida responda korpo kaj HTTP-eraro ĉe la celo ne ĉiuj pliigu nediferencan nombrilon de "mortinta prokso".

Uzu horloĝon de pasinta tempo por malvarmigo ene de la procezo. Monotona horloĝo malhelpas, ke mallonga atendo dependu de ĝustigo de la murhorloĝo. Ne konservu monotonan tempostampon kvazaŭ ĝi estus portebla dato kunhavata de aliaj maŝinoj; distribuita planilo bezonas aparte difinitan modelon de tempo kaj posedo.

Reakiro ne devas liberigi stampedon

Kiam la limdato pasas, permesu malgrandan reakiran provon anstataŭ sendi la tutan atendovicon samtempe. Sukcesa provo povas restarigi taŭgecon; plia fiasko povas plilongigi la paŭzon laŭ limigita politiko.

Elektu la provon por la tasko, kiun ĝi devas antaŭdiri. Sukcesa TCP-konekto ne estas kompleta HTTP- aŭ SOCKS-transakcio. Nerilata IP-kontrolpaĝo ne pruvas, ke la bezonata celo estas atingebla aŭ permesata.

Neniu universala malvarmiga daŭro sekvas el la vorto prokso. Fiksu ĝin laŭ la latencobudĝeto de la operacio, la konduto de la servo kaj la sekvoj de plia malsukcesa provo. Konservu la rikordon de la finpunkto, por ke provizora interrompo ne silente fariĝu daŭra perdo de kapacito.