Biblioteca Ticketing para Python ​

Repositorio ​

Ejemplo ​

Ejemplo básico ​

Cree un broker al iniciar la aplicación y compártalo. wait=0 es un intento inmediato sin cola, máximo 255 s; lease es 1–250 s. El minimum-work budget final es obligatorio y puede ser cero. Las fracciones de segundo se redondean hacia arriba y los valores fuera de rango o un budget mayor que el lease normalizado se rechazan antes de enviar, nunca se clampan.

from saro_ticketing import TicketBroker

broker = TicketBroker.connect("127.0.0.1:5225")
await broker.wait_ready(5)

async with await broker.acquire("key", 5, 30, 2) as ticket:
    token = ticket.token
    ...  # Verify/update token high-water and write in the same DB transaction.

Synchronous bridge:

with broker.acquire_sync("key", 5, 30, 2) as ticket:
    token = ticket.token
    ...  # Same DB transaction fencing and business write.

El close/drop automático es un release bounded best-effort. Use la API de release explícito si importa el resultado. El token debe aplicar fencing al write DB protegido dentro de la misma transaction.

Conviene saber (comportamiento) ​

• Si pudo enviarse un byte, perder la respuesta definitiva produce Indeterminate. No se reenvía A automáticamente con el mismo owner; el caller no entra en la sección crítica.
• Cancel antes de send es unsent; tras possible-send cierra la sesión. Si se parseó a la vez un grant token, intenta un release compensatorio exact-token limitado.
• M, todos los E y respuestas malformed/oversized/unknown son session-fatal. Acquires possible-send no resueltos quedan Indeterminate.
• B es rechazo definitivo de capacity y vuelve inmediatamente. Sin retry interno; el caller puede iniciar acquire nuevo con owner nuevo y backoff de aplicación.
• Releases explícitos/compensatorios reintentan exact token solo durante 5 segundos absolutos desde call/enqueue. R éxito, N ausente/no actual; sin respuesta final es error, nunca éxito supuesto.
• Solo se entrega Ticket con tiempo conservador positivo suficiente para work budget. Trabajo superior a 250 s es unsupported antes de enviar.
• El fencing DB con token es obligatorio: en la misma transaction rechace token <= stored_high_water, actualice high-water y haga business write antes de commit/rollback y release.

Opciones de seguridad (Token · TLS) ​

Todas las opciones son opcionales. token debe coincidir con client_tokens del servidor, y TLS tiene cuatro modos: desactivado / almacén de confianza del sistema / una CA indicada / omitir verificación (solo para pruebas).

broker = TicketBroker(
    ["10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"],
    token="123",
    tls="system-roots",  # "off" | "insecure-skip-verify" | ruta a un archivo CA
)

Puedes generar la configuración del token, TLS y el clúster en el lado del servidor en la página Despliegue del servidor Ticketing.