Squid retry_on_error: د حالت کوډونه او بدیلې لارې

په Squid کې retry_on_error په نوم یو انتخاب شته، خو نوم یې له خپل ګټور تفسیر پراخ دی. دا نه معنا کوي چې هر ناکامه غوښتنه به بې پایه تکرار شي تر څو چې پاڼه کار وکړي.

په هغو نسخو کې چې دا لارښوونه ملاتړ کوي، دا په ډیفالټ توګه بند دی. مستند تکرار لړلیک 403، 500، 501، 502، 503 او 504 دی، او غوښتنه د بل کار کوونکي منزل له لارې هڅه کوي. دا په هغه درجه بندي کې ځانګړی اهمیت لري چې بدیلې لېږد لارې لري. دا یوازې د هماغه ساکټ څخه هماغه سرور ته د وخت له مخې بیا هڅه نه ده.

لومړی ناکامي ونوموئ

پروکسي ته د نښلېدو پر مهال رد، د پروکسي تصدیق ناکامي، له سرچینې څخه HTTP تېروتنه او د سپارلو له پیل وروسته پرې شوی ځواب د تکرار ورته فرصت نه وړاندې کوي. مه تمه کوئ چې یو ترتیب به څلور واړه یو شان سمبال کړي.

د شخصي وتلې لپاره دا هم پرېکړه وکړئ چې ایا بدیله لار د منلو وړ ده. بل والد کېدای شي بل عامه سرچینې پته، تصدیق پالیسي یا شبکه یی موقعیت ولري. د هغه بدیل له لارې بریا کېدای شي هغه لامل مات کړي چې لومړی والد پرې غوره شوی و.

د اپلیکیشن عملیات بل اندېښنه راوړي: د غوښتنې تکرار کېدای شي د هغې اغېزه هم تکرار کړي. کلاینټ او سرور ته مناسبه د تکرار معناشناسي ته اړتیا ده، په ځانګړي ډول هغو عملیاتو لپاره چې ډاټا جوړوي یا بدلوي. د پروکسي ترتیب د نامعلومو پایلو د اپلیکیشن کچې مدیریت بدیل نه دی.

د خپلې دقیقې نسخې لپاره لارښوونه ولولئ؛ حواله د شتون او ډیفالټ چلند لړلیک کوي. همدا راز د غوښتنې مهالونه او هغه ټوله انتظار چې کاروونکی یې ویني په پام کې ونیسئ. یوه اضافي لېږد هڅه کېدای شي پاتې وخت مصرف کړي پرته له دې چې غوره پایله ورکړي.

کله چې ناڅاپي ناکامۍ څیړئ، حالت، غوره شوی والد یا منزل او د هڅو ترتیب ثبت کړئ. که نه، تکرارونه کېدای شي یوه تکراري د لارې ستونزه د عموماً ورو وېبپاڼې په څېر ښکاره کړي او هغه لاره پټه کړي چې واقعاً ناکامه شوې ده.