Message Queue (enqueue) und Scheduled Task (scheduled_task) - Funktionalität unter Mittwald

[Marc_E]

Hallo,

Bei mir leeren und verändern sich die Datenbanktabellen enqueue und scheduled_task einfach nicht.
Für eine Funktionalität sollten laut AndreHerking auf diesem Post Scheduled Tasks und Cronjobs dies aber tun.

Hier unser Setup:
SW 6 6.5.3.1 / PHP 8.1.18 / Hosting bei Mittwald / Memory Limit in php.ini ist auf 512mb

• Der Admin Worker ist per shopware.yaml deaktiviert.

Es wurde eine messagequeue.sh Datei angelegt in /files ablegegt mit diesem Inhalt:

 #!/bin/bash
php /html/shopware/sw6/bin/console messenger:consume default --time-limit=60 --memory-limit=512M

Sowie eine scheduledtasks.sh Datei in das selbe Verzeichnis mit diesem Inhalt:

#!/bin/bash
php /html/shopware/sw6/bin/console scheduled-task:run --time-limit=60

Im Mittwald Account wurden zwei Cronjobs angelegt die jede Minute ausgeführt werden so:

In den Datenbanktabellen enqueue und scheduled_task (Keine Zeitveränderungen schon seit Tagen) tut sich allerdings nichts:

Ich bin zwar in der Konsole nicht fit, habe aber, so glaube ich die Befehle der Scripte dort auch ausführen können, jedoch hat sich in den Tabellen nichts geändert.

Kann mir vielleicht jemand sagen, ob ich was übersehen habe?

Danke.

[Max_Shop]

Message Queue

Versuche es mal mit bin/console messenger:consume async --time-limit=60 --memory-limit=512M

Was passiert, wenn du die Befehle direkt in der CLI eingibst, mit --vvv ergänzt?

[Marc_E]

Das hier:

Nach dem ersten Befehl tut sich in der Datenbank nachwievor nichts.

[Max_Shop]

Du musst das --vvv wohl doch weg lassen. Sorry, mein Fehler.

[Marc_E]

Das habe ich im ersten Befehl auch getan jedoch hat sich nichts geändert in der Datenbank und im Shopware backend unter:

[Max_Shop]

Der Screenshots zeigt die Tasks. Die werden mit dem anderen Befehl ausgeführt.

Innerhalb der Tasks gibt es auch einen Task, die Messeges abzuarbeiten. Da wird dann der von dir angewandte Befehl ausgeführt.

Versuche in der CLI noch einmal anstatt async default und dann auch noch ohne default.

[PromoID]

Ich kenne mich bei Mittwald nicht aus - aber bei uns werden die Cronjobs über eine .php Datei ausgeführt:

ALL INKL

<?php
exec("/usr/bin/php81 /www/htdocs/******/******/shopware/bin/console messenger:consume default --time-limit=60 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>

<?php
exec("/usr/bin/php81 /www/htdocs/*****/*****/shopware/bin/console scheduled-task:run --time-limit=60 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>

Und bei webgo wird direkt in die CronJobs eingetragen, z.B.:
/usr/bin/php8.0 /home/www/***/bin/console messenger:consume default --time-limit=60

Die richtige PHP Version muss bei beiden Providern noch rein…

Es kann auch sein das eins der Tasks spinnt, einfach mal manuell umstellen und nochmal durchlaufen lassen.

[Marc_E]

Habe ich versucht, selbes Ergebnis.

[Marc_E]

Ist das für php8.1 der richtige befehl? Bzw. wie bekomme ich das raus?

[PromoID]

Am besten den Provider kurz anrufen und nachfragen (oder per Mail).

Nur mal so gefragt - wenn du in der Console, in deinem Shopwareverzeichnis die Commands durchlaufen lässt - da passiert nichts?

Also ganz einfach folgendes:
php bin/console messenger:consume --time-limit=60
php bin/console scheduled-task:run --time-limit=60

In deinem Screenshot sehe ich das „php“ überhaupt nicht ^^ Da fängst du direkt mit bin/console an.

PS: Lass die beiden Befehle mal 2-3x durchlaufen.

[Marc_E]

Also ich bin in das Shopware Verzeichnis gewechselt und habe den Befehl mit „php“ ausgeführt, siehe Screenshot:

Dann musste ich einen receiver wählen (habe default genommen weil das von Mittwald so vorgegeben ist).
Das Ergebnis bleibt aber das selbe.
Beim zweiten Befehl kam das dabei raus:

Leider beides ohne veränderte Ergebnisse in der Datenbank.

[Marc_E]

Der Provider hat mir beim Einrichten der Scripte geholfen:

zunächst habe ich in den beiden Skripten den Wert für das „–time-limit“ auf 55 Sekunden reduziert.

Dieser Wert sollte immer etwas unterhalb des Ausführintervalls des Cronjobs liegen.
Ansonsten kann es zu Problemen kommen, da der vorausgehende Prozess noch nicht abgeschlossen wurde, während bereits ein neuer Prozess gestartet wird.
Laut Cronjob-Log dürfte das am gestrigen Tag auch zu Problemen geführt haben.

Die Jobs scheinen nun laut „scheduled_task“-Tabelle erfolgreich abgearbeitet zu werden.

Die Tabelle enqueue ist allerdings immer noch voll mit Einträgen und leert sich nicht. Soll die das überhaupt?

[area-net-gmbh]

Anbei der Screenshot von den beiden Cronjobs in einem Mittwald-Paket. Läuft wunderbar. Ist aktuell auf 5 Minuten eingestellt.

Entsprechend Admin-Worker deaktivieren und E-Mail-Versand auf asynchron schalten. E-Mail-Template im Admin zum Test verschicken. Wenn die Mail ankommt, passt in der Regel alles.

framework.yaml

framework:
    mailer:
        message_bus: 'messenger.default_bus'

shopware.yaml

shopware:
  admin_worker:
    enable_admin_worker: false

[Marc_E]

In der befüllten enqueue Tabelle waren im übrigen immer sie selben Zeilen die sich nie geändert haben.
Alle hatten einen ungültigen Zeitstempel, der mit hoher Wahrscheinlichkeit dafür verantwortlich war weshalb die nicht gelöscht wurden.
Ich habe sie jetzt alle einfach aus der Tabelle gelöscht.

[sunflower]

seltsam, die Anleitung von Mittwald sieht etwas unterschiedlich aus.
Ist das dann eine „veraltete“ Anleitung vom 30.11.2022?
Ich habe mehrere SW6-Installationen mit dieser Konfiguration bei Mittwald laufen…

[canetti]

Hallo,
ich muss den alten Thread mal wieder hoch bringen, da ich auch gerade ein Problem mit meiner „Warteschlange“ laut der Frosch-Erweiterung habe. Ungefähr alle 24 Stunden schaltet sich die Lampe auf orange weil in meiner „Warteschlange“ CollectEntityDataMessage und messenger.transport.low.priority mit 1 gelistet werden - und nicht mit 0 wie die anderen Dienste.

Frage: Ihr schreibt hier von einer Tabelle enqueue. In meinem aktuellen Shopware 6.6.1.1 gibt es keine Tabelle enqueue. Aus welcher Tabelle holt sich Frosh die Daten?

[MichaelF]

Schließe mich hier canetti an. Beobachte dasselbe Problem (hosterunabhängig), ebenfalls unter 6.6.1.1. Open Queues: 2995 mins
messenger.transport.scheduler_shopware: size unknown

[area-net-gmbh]

Unter 6.6 müsst ihr den Befehl für den Cronjob anpassen.: shopware/UPGRADE-6.6.md at v6.6.1.2 · shopware/shopware · GitHub

Aus

php bin/console messenger:consume async

wird

php bin/console messenger:consume async low_priority

Gerade bei Major-Updates kommt man über ein Lesen des obigen Upgrade-Guides nicht herum.

[MichaelF]

Daran lag es bei mir. Vielen Dank!

Habe low_priority hinzugefügt.