Squid retry_on_error: স্ট্যাটাস কোড ও বিকল্প পথ

Squid-এ retry_on_error নামের একটি অপশন আছে, কিন্তু নামটি এর উপযোগী ব্যাখ্যার চেয়ে বেশি বিস্তৃত। এর অর্থ এই নয় যে প্রতিটি ব্যর্থ অনুরোধ পৃষ্ঠাটি কাজ না করা পর্যন্ত অসীমভাবে পুনরাবৃত্তি হবে।

এই নির্দেশিকা সমর্থনকারী সংস্করণগুলিতে এটি ডিফল্টভাবে বন্ধ। এর নথিভুক্ত পুনরাবৃত্তি তালিকা হলো 403, 500, 501, 502, 503 এবং 504, এবং এটি অনুরোধটি অন্য একটি কার্যকর গন্তব্যের মাধ্যমে চেষ্টা করে। বিকল্প ফরওয়ার্ডিং পথ থাকা শ্রেণিবিন্যাসে এটি বিশেষভাবে প্রাসঙ্গিক। এটি একই সকেট থেকে একই সার্ভারে শুধু সময়ভিত্তিক পুনরায় চেষ্টা নয়।

প্রথমে ব্যর্থতার নাম দিন

প্রক্সিতে সংযোগের সময় প্রত্যাখ্যান, প্রক্সি প্রমাণীকরণ ব্যর্থতা, উৎসের HTTP ত্রুটি এবং বিতরণ শুরু হওয়ার পর কেটে যাওয়া প্রতিক্রিয়া একই পুনরায় চেষ্টার সুযোগ দেয় না। একটি সেটিং চারটিকেই একভাবে সামলাবে বলে আশা করবেন না।

ব্যক্তিগত এক্সিটের জন্য বিকল্প পথ গ্রহণযোগ্য কি না তাও ঠিক করুন। অন্য প্যারেন্টের অন্য একটি পাবলিক সোর্স ঠিকানা, প্রমাণীকরণ নীতি বা নেটওয়ার্ক অবস্থান থাকতে পারে। সেই বিকল্পের মাধ্যমে সাফল্য প্রথম প্যারেন্ট বেছে নেওয়ার কারণ লঙ্ঘন করতে পারে।

অ্যাপ্লিকেশন অপারেশন আরেকটি উদ্বেগ আনে: অনুরোধ পুনরাবৃত্তি করলে তার প্রভাবও পুনরাবৃত্তি হতে পারে। ক্লায়েন্ট ও সার্ভারের উপযুক্ত পুনরায় চেষ্টার সেমান্টিক্স দরকার, বিশেষত এমন অপারেশনের জন্য যা ডেটা তৈরি বা পরিবর্তন করে। প্রক্সি সেটিং অনিশ্চিত ফলাফলের অ্যাপ্লিকেশন-স্তরের ব্যবস্থাপনার বিকল্প নয়।

আপনার সঠিক সংস্করণের জন্য নির্দেশিকাটি পড়ুন; রেফারেন্সে প্রাপ্যতা ও ডিফল্ট আচরণ তালিকাভুক্ত। পাশাপাশি অনুরোধের সময়সীমা ও ব্যবহারকারীর দেখা মোট অপেক্ষা নজরে রাখুন। অতিরিক্ত ফরওয়ার্ডিং চেষ্টা ভালো ফল না দিয়েই বাকি সময় খরচ করতে পারে।

মাঝে মাঝে হওয়া ব্যর্থতা তদন্তের সময় স্ট্যাটাস, নির্বাচিত প্যারেন্ট বা গন্তব্য এবং চেষ্টার ক্রম লিপিবদ্ধ করুন। নইলে পুনরাবৃত্তি বারবার ঘটা রাউটিং সমস্যাকে সাধারণভাবে ধীর ওয়েবসাইটের মতো দেখাতে পারে, আসলে ব্যর্থ হওয়া পথটি লুকিয়ে রেখে।