Ticketing
Documentation

B · Occupé

Structurerefresh

La réponse envoyée lorsqu'une requête d'acquisition (A) arrive mais que la file d'attente de cette clé a atteint la limite du serveur (max_waiters, 16 384 par défaut) : il n'a donc pas été possible de la mettre en file. Le verrou n'a pas été obtenu, mais la requête elle-même n'a rien d'incorrect.

owner est le corrélateur : la valeur envoyée dans la requête, renvoyée telle quelle. Elle permet de savoir exactement quelle tentative d'acquisition a été refusée (Règles de correspondance des réponses).

Traitement côté client

Il ne faut pas échouer immédiatement. Tant qu'il reste du budget wait, réessayez avec un backoff (dans les clients officiels : à partir de 10 ms, en doublant jusqu'à 200 ms). Dès que la file se vide, l'essai suivant s'y range normalement. Ce n'est que si la saturation persiste jusqu'à épuisement du wait qu'il faut signaler l'erreur « occupé » à l'appelant.

Les nouveaux essais doivent utiliser le même owner — sinon, si l'acquisition a fini par aboutir entre-temps, le serveur ne la reconnaîtra pas comme étant la même.

Notation des octets : op est un caractère ASCII, owner est binaire (u64, big-endian), et key est du texte UTF-8 (longueur variable, notée N dans la structure). Le \n final est 0A. L'en-tête fixe est une valeur binaire et peut contenir 0x0A : il faut donc le consommer d'abord selon son nombre d'octets, avant de chercher le retour à la ligne.

Flux

Client
Serveur
A · acquisition (key · owner)
la file de cette clé a atteint max_waiters
B · occupé (owner en écho)
après le backoff, nouvel essai avec le même owner
A · acquisition (nouvel essai)
dès qu'une place se libère → A · acquis (token)
requêteréponse

Cette limite n'est pas un contrôle de flux, mais une protection de la mémoire — elle empêche un client authentifié d'empiler indéfiniment des attentes sur une seule clé et d'épuiser la mémoire du serveur. Elle est fixée avec une large marge au-dessus du fan-out normal : en exploitation normale, cette réponse ne se rencontre donc pas. La limite se règle via max_waiters dans la configuration du cluster.