Squid retry_on_error՝ կարգավիճակի կոդեր և այլընտրանքային ուղիներ

Squid-ում կա retry_on_error անունով ընտրանք, սակայն անունն ավելի լայն է, քան դրա օգտակար մեկնաբանությունը։ Այն չի նշանակում, որ յուրաքանչյուր ձախողված հարցում կկրկնվի անվերջ, մինչև էջը աշխատի։

Այս հրահանգը աջակցող թողարկումներում այն անջատված է լռելյայն։ Փաստաթղթավորված կրկնման ցանկն է՝ 403, 500, 501, 502, 503 և 504, և հարցումը փորձվում է մեկ այլ աշխատող նպատակակետով։ Սա հատկապես կարևոր է այլընտրանքային փոխանցման ուղիներ ունեցող հիերարխիայում։ Սա միայն նույն սոքետի ժամանակային կրկնափորձ չէ նույն սերվերին։

Նախ անվանեք խափանումը

Փոխանցակցին միանալիս մերժումը, փոխանցակցի նույնականացման ձախողումը, աղբյուրի HTTP սխալը և առաքման մեկնարկից հետո կտրված պատասխանը չեն առաջարկում կրկնման նույն հնարավորությունը։ Մի սպասեք, որ մեկ կարգավորումը չորսին էլ նույն ձևով կվերաբերվի։

Մասնավոր ելքի համար որոշեք նաև՝ արդյոք այլընտրանքային ուղին ընդունելի է։ Մեկ այլ ծնող կարող է ունենալ այլ հանրային աղբյուրի հասցե, նույնականացման քաղաքականություն կամ ցանցային դիրք։ Այդ այլընտրանքով հաջողությունը կարող է խախտել առաջին ծնողի ընտրության պատճառը։

Հավելվածի գործողությունները մեկ այլ մտահոգություն են բերում․ հարցման կրկնությունը կարող է կրկնել դրա ազդեցությունը։ Հաճախորդին և սերվերին անհրաժեշտ է համապատասխան կրկնման իմաստաբանություն, հատկապես տվյալներ ստեղծող կամ փոփոխող գործողությունների համար։ Փոխանցակցի կարգավորումը չի փոխարինում անորոշ արդյունքների հավելվածային մակարդակի կառավարմանը։

Կարդացեք հրահանգը ձեր ճշգրիտ թողարկման համար․ տեղեկատուն թվարկում է հասանելիությունը և լռելյայն վարքը։ Հաշվի առեք նաև հարցման ժամկետները և օգտատիրոջը տեսանելի ընդհանուր սպասումը։ Լրացուցիչ փոխանցման փորձը կարող է սպառել մնացած ժամանակը՝ առանց ավելի լավ արդյունք տալու։

Ընդհատվող խափանումները հետաքննելիս գրանցեք կարգավիճակը, ընտրված ծնողը կամ նպատակակետը և փորձերի հաջորդականությունը։ Հակառակ դեպքում կրկնությունները կարող են կրկնվող երթուղային խնդիրը ներկայացնել որպես ընդհանուր դանդաղ կայք՝ թաքցնելով այն ուղին, որն իրականում ձախողվել է։