B · مصروف ​

حصول کی درخواست (A) آئی، مگر اس کلید کی قطار سرور کی حد (max_waiters، ڈیفالٹ 16,384) کو پہنچ چکی تھی، اس لیے اسے قطار میں کھڑا نہیں کیا جا سکا۔ یہ لاک نہ ملنے کی بات ہے، درخواست کے غلط ہونے کی نہیں۔

owner وہی قدر ہے جو درخواست میں بھیجی گئی تھی، ہو بہو واپس کیا گیا ربط دینے والا شناخت کنندہ — اس سے ٹھیک ٹھیک معلوم ہو جاتا ہے کہ کون سی حصول کی کوشش مسترد ہوئی (جواب ملانے کے اصول)۔

کلائنٹ کی کارروائی ​

فوراً ناکام نہیں کرنا چاہیے۔ جب تک wait کا بجٹ باقی ہے، backoff کے ساتھ دوبارہ کوشش کریں (سرکاری کلائنٹس: 10ms سے شروع کر کے 200ms تک دگنا)۔ قطار خالی ہوتے ہی اگلی کوشش معمول کے مطابق قطار میں لگ جاتی ہے۔ اگر wait ختم ہونے تک قطار بھری ہی رہے، تب کال کرنے والے کو "مصروف" خرابی سے مطلع کریں۔

دوبارہ کوشش اسی owner سے بھیجنی چاہیے — تاکہ اگر اس دوران حصول ہو بھی چکا ہو تو سرور اسے وہی حصول سمجھے۔

بائٹ نوٹیشن: op ایک ASCII حرف ہے، owner بائنری (u64، big-endian) ہے، اور key UTF-8 متن ہے (متغیر لمبائی، ڈھانچے میں N کے طور پر)۔ آخری \n 0A ہے۔ فکسڈ ہیڈر بائنری قدر ہے جس میں 0x0A آ سکتا ہے، اس لیے نئی لائن تلاش کرنے سے پہلے بائٹ کی تعداد کے مطابق پہلے کھپانا ہوگا۔

بہاؤ ​

یہ حد فلو کنٹرول نہیں بلکہ میموری کی دفاعی لکیر ہے — یہ کسی تصدیق شدہ کلائنٹ کو ایک ہی کلید پر لامحدود انتظار جمع کر کے سرور کی میموری ختم کرنے سے روکتی ہے۔ یہ عام fan-out سے کہیں زیادہ فراخ رکھی گئی ہے، اس لیے عام حالات میں یہ جواب دیکھنے کو نہیں ملتا۔ حد کو کلسٹر کنفیگ کے max_waiters سے ایڈجسٹ کیا جاتا ہے۔