Squid retry_on_error: olekukoodid ja alternatiivsed teed
Kasutage Squid retry_on_error dokumenteeritud oleku- ja alternatiivse sihtkoha ulatuses, mitte universaalse päringu kordamise seadistusena.
Squidis on valik nimega retry_on_error, kuid nimi on laiem kui selle kasulik tõlgendus. See ei tähenda, et iga ebaõnnestunud päringut korratakse lõputult, kuni leht hakkab tööle.
Seda direktiivi toetavates versioonides on see vaikimisi väljas. Dokumenteeritud korduste nimekiri on 403, 500, 501, 502, 503 ja 504 ning päringut proovitakse teise töötava sihtkoha kaudu. See on eriti oluline hierarhias, kus on alternatiivsed edastusteed. See ei ole lihtsalt sama sokli ajastatud korduskatse samasse serverisse.
Nimetage esmalt tõrge
Keeldumine puhverserveriga ühenduse loomisel, puhverserveri autentimise tõrge, lähtekoha HTTP-viga ja vastus, mis katkestati pärast tarne algust, ei paku sama kordusvõimalust. Ärge oodake, et üks seadistus kohtleb kõiki nelja ühtemoodi.
Privaatse väljundi puhul otsustage ka, kas alternatiivne tee on vastuvõetav. Teisel vanemal võib olla teine avalik lähteaadress, autentimispoliitika või võrgukoht. Selle alternatiivi kaudu õnnestumine võib rikkuda põhjust, miks esimene vanem valiti.
Rakenduse toimingud toovad veel ühe mure: päringu kordamine võib korrata selle mõju. Klient ja server vajavad sobivat kordamissemantikat, eriti toimingute puhul, mis loovad või muudavad andmeid. Puhverserveri seadistus ei asenda ebakindlate tulemuste käsitlemist rakenduse tasandil.
Lugege direktiivi oma täpse versiooni jaoks; viide loetleb saadavuse ja vaikekäitumise. Pidage silmas ka päringu tähtaegu ja kasutajale nähtavat koguootust. Täiendav edastuskatse võib kulutada järelejäänud aja ilma parema tulemuseta.
Vahelduvate tõrgete uurimisel kirjutage üles olek, valitud vanem või sihtkoht ja katsete järjekord. Muidu võivad kordused muuta korduva marsruutimisprobleemi üldiselt aeglase veebisaidi looks, varjates tee, mis tegelikult ebaõnnestus.