OrderSprinter-Forum

Wir haben nach wir vor das Problem, dass bei allen Restaurants (wahrscheinlich seit der letzten Version 2.8.5) Bestellungen "verschwinden".

Kellner bucht auf den Tisch einige Getränke und Speisen. Drückt dann auf Arbeitsbon und das Tablet springt zurück auf entweder Tisch- oder Raumauswahl. Es sieht also alles so aus, wie es sein sollte.

Nun kommts:
Immer häufiger sind die Buchungen im wahrsten Sinne des Wortes verschwunden. Weder im Tischprotokoll zu sehen, noch im Access.log des Apache, dass vom Tablet etwas gesendet wurde - auch sonst keine Fehlermeldung, nirgends.

Wir sind ein wenig am verzweifeln weil die Kassen inkl. TSE in allen Restaurants vorher normal liefen - OHNE diesen Effekt.

Hat irgendjemand sonst auch dieses Problem?

Hallo Lutz,

du hast mir erzählt und auch im Forum beschrieben, dass du ziemlich tiefgehende Anpassungen an der Software vornimmst. Das ist auch völlig ok, aber da von einem solchen Fehler bisher noch nicht berichtet wurde, frage ich mich, ob die Probleme nicht mit deinen Softwareänderungen zusammenhängen.

Es tut mir echt leid, aber mir fehlt wirklich die Zeit und auch die Lust, Softwarefehlern nachzuforschen, die mit einer gewissen Wahrscheinlichkeit nicht durch mich verursacht wurden.

Wenn wie du schreibst, nicht mal im Access-Log irgendwas zu sehen ist, wird der Request offenbar gar nicht bis zum Server durchgekommen sein. Trotzdem würde ich an deiner Stelle das Logging auf E_ALL hochsetzen und das error_log anschauen. Aber ich vermute, dass der Fehler nicht auf Serverseite liegt.

Viele Grüße,

Stefan

Hallo Stefan,

wir haben das Problem wahrscheinlich eingrenzen können und wahrscheinlich behoben. Wir haben testweise beim Kunden eine unveränderte Version Deiner Software eingesetzt und bei "Überlast" (30 Kellner, alle Tische voll besetzt) exakt den selben Fehler beobachten können. Mal sehen, wir warten nun wieder auf einen Tag mit massivem Ansturm. Sonst Trat der Fehler "auch so" mal auf. Seit ein paar Tagen nicht mehr.

Viele Grüße,

Lutz

Hallo Stefan,

da wir seit Monaten bei den großen Restaurants mit den Problem "Bon kommt nicht/Bestellung nicht gebucht" kämpfen haben wir das weiter untersucht.

Der Fehler ist reproduzierbar:

2 Kellner, geben eine Bestellung ein und drücken GLEICHZEITIG auf ihren jeweiligen Tablet auf Arbeitsbon. Dann wird eine der beiden Bestellungen nicht ausgeführt. Wir haben dazu ein Logfile gebaut, welches die ID für die entsprechende Transaktion wegschreibt. In der Datentabelle os_queue kommt eine Transaktion einfach nicht an. Der Server liefert den Tablets jeweils ein "ok" und die Transaktionsnummer zurück. Wir haben in der os_queue bei den beiden Restaurants in denen der Effekt auftritt Lücken in der ID.

Offenbar geht hier bei der gleichzeitigen Transaktionsverarbeitung mit unterschiedlichen Values etwas schief.

Wir können Dir den Effekt gern per Fernwartung zeigen, gern auch zur Unzeit.

UPDATE:

Wir haben etwas am Code geändert. Bevor aus der Methode "addProductListToQueueCore" am Ende mit Status ok rausgegangen wird prüfen wir noch einmal ob die zuvor generierten QueueIDs auf wirklich in der Datenbank sind. Wenn nicht, geben wir Status "error" mit einer Fehlernachricht für die Kellner zurück mit dem Hinweis erneut auf Arbeitsbon zu drücken. Beim 2. mal geht es dann, wenn NICHT WIEDER jemand zur gleichen Zeit etwas bucht.

Hallo in die Runde,
auch wir hatten mehrfach den selben Fehler, dass Bestellungen nicht gedruckt wurden, aber im Tischprotokoll zu sehen waren. Nutzen aktuell die Version 2.8.7 in unverändertem Zustand.
Viele Grüße Skifan

Hallo,

ich kann den Fehler in meiner Umgebung trotz vieler Versuche nicht reproduzieren. Aber es wäre schön, wenn ich ein Logfile des Webservers (error_log) bekäme mit Angabe, wann der Fehler aufgetreten ist, damit ich dann konkret das Log zu diesem Zeitpunkt analysieren kann. Allerdings muss es ein Log von einem Originalsystem sein, Fehler in vom Anwender angepassten Source-Code werde ich nicht suchen.

Gruß,

Stefan

Hallo Stefan,

das Problem liegt in Verarbeitung der PDO Transaction in der Methode "addProductListToQueueCore" in der queuecontent.php
Wenn zwei zeitgleiche Requests zur Anlage einer Bestellung kommen, dann fällt einer auf die Nase, weil die Transaktion nicht ausgeführt
wird. Trotz der Tatsache, dass das "$pdo->commit" die Ausführung mit true quittiert, werden die Daten der Transaktion nicht persistiert.
Die sind einfach weg. Dieses liegt offenbar an der Dauer der Transaction.

Wir haben uns nun mit einem Workaround geholfen, dass wir vor dem Return "OK" nochmal checken ob die QueueID der Transaction auch
wirklich in der Datenbank steht. Falls nicht, dann bekommt der User einen "Error" angezeigt und muss nochmal auf Arbeitsbon klicken.
Ein Dirty-Hack ist auch, wenn man direkt beim Start der Methode die Ausführung des Codes willkürlich um 1-5 Sekunden verzögert, so das eine zeitgleiche Ausführung fast immer vermieden wird.
In diesem Bereich haben wir zum einen keine Anpassungen vorgenommen und zum anderen entsteht bei dem oben Beschriebenen Bug auch keine Fehlermeldung in den Apache Logs.

Hallo Lutz,

kann es sein, dass du an der InnoDB-Konfiguration gedreht hast, um eine vermeintliche bessere Performance zu erreichen? Interessant wäre zum Beispiel, welchen Isolation-Level du als Standard eingestellt hast. Das bekommst du mit diesem Kommando raus:
Das sollte mindestens auf REPEATABLE-READ stehen! "Read Uncommitted" und "Read Committed" reichen nicht aus, "Serializable" würde alles sehr verlangsamen und verwende ich deswegen explizit nur an einer Stelle!

Wenn es beispielsweise auf "Read (un)committed" steht, würde es das von dir beobachtete Verhalten erklären, wäre aber ein ziemlicher Fehler beim grundsätzlichen Setup des Systems!

Das sleep(rand(1-5)) (du meinst bestimmt "1,5" statt "1-5") am Anfang der Methode addProductListToQueueCore() würde das Problem auch nicht lösen, denn damit hast du zwar JEDE Abarbeitung von Bestellungen um ein paar Sekunden verlangsamt (da es ein synchroner REST-Call ist, frierst du das UI sogar beim sleep ein), aber Kollisionen können trotzdem passieren, nur eben nicht mehr, wenn beide Parteien absolut zeitgleich eine Bestellung an den Server schicken.

Gruß,

Stefan

Hallo Stefan,

nein, daran haben wir nichts geändert das ist nach wie vor die Installation aus seinem Script. Das Problem ist inzwischen auf zwei Kassen beliebig reproduzierbar. Du nimmst einfach 2 Tablets, klickst auf 2 unterschiedlichen Tischen, jeweils ein Produkt und versucht annähernd zeitgleich auf Arbeitsbon zu drücken.

Hallo in die Runde,
wie oben von mir beschrieben, hatten wir das Problem auch ab und zu. Leider kann ich das Problem, wie beschrieben zu Hause, nicht mehr reproduzieren. Evtl. liegt es daran, dass wir bei unserer Veranstaltung einen PC mit einer älteren PHP Version hatten.
Ich habe heute XAMPP mit PHP Version 8.2.12 installiert, die php.ini wie beschrieben angepasst, Ordersprinter komplett neu aufgesetzt und die config Datei von unserer Veranstaltung importiert.
Dann habe ich versucht zeitgleich 2 Produkte zu bestellen. Es kommt jeder Bon an.