Stopp ei proxyrotasjonsløkke frå å gå i det uendelege

Ein proxypool kan gjere eit enkelt avbrot til ei travel løkke. Vel ei adresse, feilar, vel ei anna, feilar igjen. Viss kvar endepunkt er utilgjengeleg fordi ditt eige nettverk er nede, løyser byte av adresser aldri årsaka.

Gje operasjonen eit budsjett før du vel den første proxyen frå poolen eller lista over gratis proxyar: eit avgrensa tal forsøk, avgrensa ventetider for tilkopling og lesing, og ein frist for heile oppgåva. Ein Requests-timeout styrer den dokumenterte tilkoplings- eller leseåtferda si; han avgrensar ikkje i seg sjølv ei løkke som held fram med å sende nye førespurnader.

Avgjer kva som fortener eit nytt forsøk

• Ei avvist proxytilkopling kan grunngje å prøve eit anna endepunkt.
• Eit svar frå destinasjonen treng si eiga tolking. Å ta imot ein HTTP-feil provar at ein førespurnadsveg vart fullført.
• Ein proxyautentiseringsfeil krev at endepunktet og kontoen blir sjekka, i staden for å hamre dei same påloggingsdetaljane gjennom ei veksande liste.

Ta vare på den opphavlege unntaket eller statusen saman med forsøksregistreringa. Ei avsluttande melding som berre seier «alle proxyar feila», skjuler om feila i det heile hadde same årsak.

Å helsesjekke kvar proxy før kvar ekte førespurnad legg til endå ein førespurnad og kan framleis ikkje garantere at den neste lukkast. Bruk fersk helseinformasjon om att der det passar til oppgåva, og la deretter den ekte operasjonen rapportere sitt eige resultat.

Eit nytt forsøk kan gjenta arbeidet

For ei skriveverna henting er det vanlegvis enklare å byte til ein annan proxy enn å spele av ei innsending på nytt. Viss ei tilkopling fell etter at eit kjøp eller ei skjemainnsending er send, kan destinasjonen alt ha handsama ho. Følg idempotensmekanismen til tenesta og HTTP-reglane for nye forsøk før arbeidet blir spelt av på nytt.

Når budsjettet er brukt opp, returner ein nyttig feil. Ein jobb som stoppar med bevis, er lettare å reparere enn ein som stille held fram med å rotere til nokon legg merke til det.