Ticketing
ডকুমেন্টেশন

B · ব্যস্ত

গঠনrefresh

অর্জন অনুরোধ (A) এসেছে, কিন্তু সেই কী-এর সারি সার্ভারের সীমায় (max_waiters, ডিফল্ট ১৬,৩৮৪) পৌঁছে যাওয়ায় তাকে সারিতে দাঁড় করানো যায়নি — এই সাড়া তা-ই জানায়। এটি লক না পাওয়ার ব্যাপার, অনুরোধ ভুল হওয়ার নয়।

owner হলো অনুরোধে পাঠানো মানটিই হুবহু ফেরত দেওয়া সম্পর্ক-নির্দেশক — কোন অর্জন-প্রচেষ্টা প্রত্যাখ্যাত হয়েছে তা নির্ভুলভাবে জানা যায় (সাড়া মেলানোর নিয়ম)।

ক্লায়েন্টের করণীয়

সঙ্গে সঙ্গে ব্যর্থ করা যাবে না। wait বাজেট বাকি থাকা পর্যন্ত ব্যাকঅফ রেখে পুনরায় চেষ্টা করুন (অফিসিয়াল ক্লায়েন্ট: ১০ms থেকে শুরু করে ২০০ms পর্যন্ত দ্বিগুণ)। সারি খালি হলেই পরবর্তী চেষ্টা স্বাভাবিকভাবে সারিতে দাঁড়িয়ে যায়। wait শেষ হওয়া পর্যন্ত পূর্ণ থাকলে তখন কলারকে "ব্যস্ত" ত্রুটি হিসেবে জানান।

পুনঃচেষ্টা একই owner দিয়ে পাঠাতে হবে — তবেই এর মধ্যে অর্জন সম্পন্ন হয়ে থাকলেও সার্ভার সেটিকে একই অর্জন হিসেবে চিনবে।

বাইট নোটেশন: op একটি ASCII অক্ষর, owner বাইনারি (u64, বিগ-এন্ডিয়ান), আর key UTF-8 টেক্সট (পরিবর্তনশীল-দৈর্ঘ্যের, স্ট্রাকচারে N হিসেবে দেখানো)। শেষের \n হলো 0A। ফিক্সড হেডার বাইনারি মান বলে এতে 0x0A থাকতে পারে, তাই নিউলাইন খোঁজার আগে বাইট-সংখ্যা অনুযায়ী আগে গ্রাস করতে হবে।

প্রবাহ

ক্লায়েন্ট
সার্ভার
A · অর্জন (key · owner)
এই কী-এর সারি max_waiters-এ পৌঁছেছে
B · ব্যস্ত (owner ইকো)
ব্যাকঅফের পর একই owner দিয়ে পুনরায় চেষ্টা
A · অর্জন (পুনঃচেষ্টা)
জায়গা খালি হলে A · অর্জিত (token)
অনুরোধপ্রতিক্রিয়া

এই সীমা ফ্লো কন্ট্রোল নয়, বরং মেমরির প্রতিরক্ষা রেখা — প্রমাণীকৃত কোনো ক্লায়েন্ট একটি কী-তে সীমাহীন অপেক্ষা জমিয়ে সার্ভারের মেমরি নিঃশেষ করে ফেলা ঠেকায়। স্বাভাবিক ফ্যান-আউটের চেয়ে অনেক উদারভাবে ধরা আছে বলে সাধারণ অবস্থায় এই সাড়া চোখে পড়ার কথা নয়। সীমাটি ক্লাস্টার কনফিগে max_waiters দিয়ে নিয়ন্ত্রণ করা হয়।