वर्तमान में परीक्षण चल रहा है: पूरा होने पर GitHub कोड खोला जाएगा।

B · व्यस्त

संरचनाrefresh

Acquire request (A) key queue या global key/waiter/pending/memory admission सीमा पर होने से स्वीकार नहीं हुई। इस request ने निश्चित रूप से lock नहीं पाया, और frame invalid नहीं था।

owner request का echoed correlator है, जिससे rejected acquire पहचाना जाता है (matching rules)।

Client handling

Official clients correlated B को तुरंत Busy/Capacity error के रूप में caller को देते हैं और वही logical acquire internally resend नहीं करते। Retry के लिए caller overall deadline और backoff तय करके नए owner से नया acquire explicitly शुरू करता है।

वास्तव में मिला B non-acquire सिद्ध करता है, इसलिए अलग नया call safe है। Response न मिले send को B न मानें; वह Indeterminate है।

बाइट अंकन: op एक ASCII वर्ण है, owner बाइनरी (u64, बिग-एंडियन) है, और key UTF-8 टेक्स्ट है (परिवर्तनशील-लंबाई, संरचना में N के रूप में दिखाया गया)। अनुगामी \n, 0A है। फ़िक्स्ड हेडर एक बाइनरी मान है जिसमें 0x0A हो सकता है, इसलिए नई लाइन खोजने से पहले उसे बाइट संख्या के आधार पर खपाएँ

प्रवाह

क्लाइंट
सर्वर
A · अधिग्रहण (key · owner)
इस कुंजी की कतार max_waiters तक पहुँच गई
B · व्यस्त (owner वापस)
Busy लौटाएँ — caller नया logical acquire तय करे
A · नया acquire (वैकल्पिक retry)
जगह होने पर → A · acquired (token)
अनुरोधप्रतिक्रिया

ये limits memory guardrails हैं। Daemon OOM से पहले नए acquires reject होते हैं और exact-token release, approved responses, cleanup व Raft recovery के लिए resources बचे रहते हैं। key_busy, per_key_limit, global_overload जैसे कारण wire नहीं, metrics/logs में अलग होते हैं।