Squidissa on retry_on_error-niminen asetus, mutta nimi on laajempi kuin sen hyödyllinen tulkinta. Se ei tarkoita, että jokainen epäonnistunut pyyntö toistetaan loputtomasti, kunnes sivu toimii.

Tätä direktiiviä tukevissa versioissa se on oletuksena pois päältä. Dokumentoitu uudelleenyrityslista on 403, 500, 501, 502, 503 ja 504, ja pyyntöä yritetään toisen toimivan kohteen kautta. Tämä on erityisen tärkeää hierarkiassa, jossa on vaihtoehtoisia välityspolkuja. Kyse ei ole vain saman pistokkeen ajastetusta uudelleenyrityksestä samaan palvelimeen.

Nimeä vika ensin

Kieltäytyminen välityspalvelimeen yhdistettäessä, välityspalvelimen todennuksen epäonnistuminen, lähteen HTTP-virhe ja toimituksen alettua katkaistu vastaus eivät tarjoa samaa uudelleenyritysmahdollisuutta. Älä odota, että yksi asetus kohtelee kaikkia neljää samalla tavalla.

Yksityiselle lähdölle päätä myös, onko vaihtoehtoinen polku hyväksyttävä. Toisella vanhemmalla voi olla toinen julkinen lähiosoite, todennuskäytäntö tai verkkosijainti. Onnistuminen tuon vaihtoehdon kautta voi rikkoa syyn, jonka vuoksi ensimmäinen vanhempi valittiin.

Sovelluksen toiminnot tuovat toisen huolen: pyynnön toistaminen voi toistaa sen vaikutuksen. Asiakas ja palvelin tarvitsevat asianmukaisen uudelleenyrityksen semantiikan, erityisesti toiminnoille, jotka luovat tai muuttavat dataa. Välityspalvelinasetus ei korvaa epävarmojen tulosten käsittelyä sovellustasolla.

Lue direktiivi tarkalle versiollesi; viite luettelee saatavuuden ja oletuskäyttäytymisen. Pidä myös pyyntöjen määräajat ja käyttäjälle näkyvä kokonaisodotus mielessä. Ylimääräinen välitysyritys voi kuluttaa jäljellä olevan ajan tuottamatta parempaa tulosta.

Kun tutkit satunnaisia vikoja, kirjaa tila, valittu vanhempi tai kohde ja yritysten järjestys. Muuten uudelleenyritykset voivat saada toistuvan reititysongelman näyttämään yleisesti hitaalta sivustolta ja kätkeä polun, joka todella epäonnistui.

Aiheeseen liittyvät artikkelit