Ticketing
दस्तावेज़

B · व्यस्त

संरचनाrefresh

यह प्रतिक्रिया बताती है कि अधिग्रहण अनुरोध (A) तो आया, लेकिन उस कुंजी की कतार सर्वर की सीमा तक पहुँच चुकी है (max_waiters, डिफ़ॉल्ट 16,384), इसलिए उसे कतार में नहीं लगाया जा सका। अर्थात् लॉक नहीं मिला — पर अनुरोध में कोई गलती नहीं थी।

owner वही मान है जो अनुरोध में भेजा गया था, ज्यों का त्यों वापस — इससे ठीक-ठीक पता चलता है कि कौन-सा अधिग्रहण प्रयास अस्वीकृत हुआ (प्रतिक्रिया मिलान नियम)।

क्लाइंट में हैंडलिंग

इसे तुरंत विफल न करें। जब तक wait का बजट बचा है, बैकऑफ़ के साथ पुनः प्रयास करें (आधिकारिक क्लाइंट: 10ms से शुरू करके 200ms तक दुगुना करते हुए)। कतार खाली होते ही अगला प्रयास सामान्य रूप से कतार में लग जाएगा। यदि 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 से समायोजित करें।