B · Belegt ​

Die Antwort darauf, dass eine Acquire-Anforderung (A) eintraf, die Anfrage aber nicht eingereiht werden konnte, weil die Warteschlange dieses Schlüssels das Serverlimit erreicht hat (max_waiters, Standard 16.384). Die Sperre wurde also nicht erlangt — die Anforderung selbst war jedoch nicht fehlerhaft.

owner ist der Wert aus der Anfrage, unverändert zurückgespiegelt — daran lässt sich genau erkennen, welcher Acquire-Versuch abgelehnt wurde (Regeln zur Antwortzuordnung).

Behandlung im Client ​

Nicht sofort scheitern lassen. Solange das wait-Budget reicht, mit Backoff erneut versuchen (offizielle Clients: beginnend bei 10 ms, verdoppelnd bis 200 ms). Leert sich die Warteschlange, reiht sich der nächste Versuch ganz normal ein. Bleibt sie bis zum Ende von wait voll, wird dem Aufrufer erst dann ein „belegt“-Fehler gemeldet.

Wiederholungen müssen denselben owner tragen — nur so erkennt der Server denselben Erwerb, falls dieser zwischenzeitlich doch zustande gekommen ist.

Byte-Notation: op ist ein ASCII-Zeichen, owner ist binär (u64, big-endian), und key ist UTF-8-Text (variable Länge, in der Struktur als N dargestellt). Das abschließende \n ist 0A. Der feste Header ist ein Binärwert und kann 0x0A enthalten — er muss daher zuerst anhand der Bytezahl verbraucht werden, bevor nach dem Zeilenumbruch gesucht wird.

Ablauf ​

Das Limit ist keine Flusskontrolle, sondern eine Schutzgrenze für den Speicher — es verhindert, dass ein authentifizierter Client durch unbegrenztes Aufstauen von Wartenden auf einem Schlüssel den Serverspeicher erschöpft. Es liegt großzügig über dem normalen Fan-out, sodass diese Antwort im Regelbetrieb nicht auftritt. Angepasst wird das Limit über max_waiters in der Cluster-Konfiguration.