Ticketing
Documentación

B · Ocupado

Estructurarefresh

La respuesta que se envía cuando llega una solicitud de adquisición (A) pero la cola de espera de esa clave ha alcanzado el límite del servidor (max_waiters, por defecto 16 384), así que no se pudo encolar. No se ha obtenido el bloqueo, pero la solicitud en sí no tiene nada de malo.

owner es el correlador: el valor enviado en la solicitud, devuelto sin cambios. Con él se sabe exactamente qué intento de adquisición fue rechazado (Reglas de emparejamiento de respuestas).

Manejo en el cliente

No falles de inmediato. Mientras quede presupuesto de wait, reintenta con backoff (en los clientes oficiales: empezando en 10 ms y duplicando hasta 200 ms). En cuanto la cola se vacíe, el siguiente intento se pone en ella con normalidad. Solo cuando la saturación persista hasta agotar el wait se debe informar del error de "ocupado" a quien llamó.

Los reintentos deben usar el mismo owner — de lo contrario, si la adquisición llegó a concretarse entretanto, el servidor no la reconocerá como la misma.

Notación de bytes: op es un carácter ASCII, owner es binario (u64, big-endian), y key es texto UTF-8 (longitud variable, mostrado como N en la estructura). El \n final es 0A. La cabecera fija es un valor binario y puede contener 0x0A, así que hay que consumirla primero según su número de bytes antes de buscar el salto de línea.

Flujo

Cliente
Servidor
A · adquirir (key · owner)
la cola de esta clave alcanzó max_waiters
B · ocupado (owner reflejado)
tras el backoff, reintenta con el mismo owner
A · adquirir (reintento)
cuando se libera un hueco → A · adquirido (token)
solicitudrespuesta

Este límite no es control de flujo, sino una defensa de memoria — impide que un cliente autenticado acumule esperas sin fin sobre una única clave y agote la memoria del servidor. Está fijado con holgura muy por encima del fan-out normal, así que en operación normal no se ve esta respuesta. El límite se ajusta con max_waiters en la configuración del clúster.