Ticketing Ruby-Bibliothek ​

Repository ​

Beispiel ​

Einfaches Beispiel ​

Einen Broker beim App-Start erstellen und teilen. wait=0 ist ein sofortiger Versuch ohne Queue, maximal 255 s; lease liegt bei 1–250 s. Das letzte Minimum-Work-Budget ist Pflicht und darf null sein. Teilsekunden werden aufgerundet; Werte außerhalb des Bereichs oder Budget über der normalisierten Lease werden vor dem Senden abgelehnt und nie geclampt.

require "ticketing"

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

ticket = broker.acquire("key", 5, 30, 2)
begin
  token = ticket.token
  # In the same DB transaction: verify/update token high-water and perform the business write.
ensure
  ticket.release
end

Automatisches Close/Drop ist ein begrenzter Best-effort-Release. Wenn das Ergebnis zählt, die explizite Release-API nutzen. Der Token muss den geschützten DB-Write in derselben Transaktion fencen.

Wissenswertes zum Verhalten ​

• Sobald ein Request-Byte gesendet worden sein könnte, führt eine verlorene definitive Antwort zu Indeterminate. Kein automatisches A mit demselben Owner; der Caller betritt die Critical Section nicht.
• Cancel vor Send ist unsent; nach possible-send wird die Session geschlossen. Wurde gleichzeitig ein Grant-Token geparst, folgt ein begrenzter kompensierender exact-token Release.
• M, jedes E und malformed/oversized/unknown Responses sind session-fatal. Ungeklärte possible-send Acquires werden Indeterminate.
• B ist definitive Capacity-Ablehnung und kommt sofort. Kein interner Retry; der Caller kann mit App-Backoff und neuem Owner einen neuen Acquire starten.
• Explizite/kompensierende Releases versuchen exact token nur bis absolut 5 Sekunden ab call/enqueue. R ist Erfolg, N bereits weg/nicht aktuell; keine finale Antwort ist Fehler, nie angenommener Erfolg.
• Ticket gibt es nur bei positiver konservativer Restzeit und ausreichendem Work-Budget. Arbeit über 250 s ist vor Send unsupported.
• Token-DB-Fencing ist Pflicht: in derselben Transaktion token <= stored_high_water ablehnen, High-water und Business Write aktualisieren, dann commit/rollback und release.

Sicherheitsoptionen (Token · TLS) ​

Alle Optionen sind optional. token sollte mit den client_tokens des Servers übereinstimmen, und TLS hat vier Modi: aus / System-Vertrauensspeicher / eine angegebene CA / Verifikation überspringen (nur für Tests).

broker = Ticketing::TicketBroker.new(
  ["10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"],
  token: "123",
  tls: "system-roots" # "off" | "insecure-skip-verify" | Pfad zu einer CA-Datei
)

Die serverseitige Token-, TLS- und Cluster-Konfiguration kannst du auf der Seite Ticketing-Serverbereitstellung erzeugen.