Ticketing
التوثيق

B · مشغول

البنيةrefresh

تصل عندما يرد طلب حصول (A) لكن طابور ذلك المفتاح قد بلغ الحد الأقصى للخادم (max_waiters، الافتراضي 16,384)، فتعذّر إدراج الطلب في الطابور. هذا يعني أن القفل لم يُحصَّل، لا أن الطلب خاطئ.

owner هو القيمة التي أُرسلت في الطلب معادة كما هي كمُعرِّف رابط — فيمكن معرفة أي محاولة حصول رُفضت بالضبط (قواعد مطابقة الاستجابات).

معالجة العميل

لا يجوز إفشال الطلب فورًا. ما دامت ميزانية wait باقية، أعد المحاولة مع تراجع (backoff) (العملاء الرسميون: يبدأون من 10 مللي ثانية ويضاعفون حتى 200 مللي ثانية). فمتى فرغ الطابور، دخلت المحاولة التالية إليه بشكل طبيعي. أما إذا ظل ممتلئًا حتى نفاد wait، فأبلغ المستدعي عندئذٍ بخطأ "مشغول".

يجب أن تُرسَل إعادة المحاولة بنفس owner — فبذلك يتعرف الخادم على الحصول ذاته حتى لو كان قد تم في تلك الأثناء.

ترميز البايتات: op حرف ASCII، وowner ثنائي (u64، big-endian)، وkey نص UTF-8 (متغير الطول، يُعرض كـ N في البنية). \n الأخير هو 0A. الرأس الثابت قيمة ثنائية قد تحتوي على 0x0A، لذا يجب استهلاكه أولًا حسب عدد البايتات قبل البحث عن سطر جديد.

التدفق

العميل
الخادم
A · حصول (key · owner)
بلوغ طابور هذا المفتاح حدَّ max_waiters
B · مشغول (صدى owner)
إعادة المحاولة بنفس owner بعد تراجع (backoff)
A · حصول (إعادة محاولة)
عند توفر مكان A · تم الحصول عليه (token)
طلباستجابة

هذا الحد ليس تحكمًا بالتدفق بل خط دفاع عن الذاكرة — يمنع عميلًا مُصادقًا من تكديس انتظارات بلا حدود على مفتاح واحد حتى استنفاد ذاكرة الخادم. وهو مضبوط بسخاء يفوق التفرع الطبيعي، لذا لن ترى هذه الاستجابة في الظروف العادية. يُضبط الحد عبر max_waiters في إعدادات العنقود.