0

Alle,Amazon Elastic Beanstalk Worker cronjob (SQS) löst gleiche Nachricht mehrmals

Ich habe eine ziemlich beunruhigende Problem mit meinem Amazon Elastic Beanstalk Arbeiter mit SQS kombiniert, die einen cron-Job Scheduling bieten soll - das alles läuft mit PHP.

Folgendes Szenario - Ich brauche ein PHP-Skript, das regelmäßig im Hintergrund ausgeführt wird und möglicherweise über Stunden läuft. Ich sah diese nette Einleitung, die genau mein Szenario zu decken scheint (AWS Worker Environments - sehen Sie die periodische Aufgabe Teil)

Also ich lese ziemlich viele HowTos und richten Sie eine EBS-Worker mit der SQS (die eigentlich automatisch während der Erstellung erfolgt des Arbeiters) und lieferte die Cron-Konfiguration (cron.yaml) in meinem Implementierungspaket.

Das Cron-Skript wird ordnungsgemäß erkannt. Der sqs-Daemon startet, Nachrichten werden in die Warteschlange gestellt und lösen mein PHP-Skript genau nach Plan aus. Das Skript wird ausgeführt und alles funktioniert einwandfrei.

Die Konfiguration der Warteschlange wie folgt aussieht: SQS configuration

jedoch nach einiger Zeit der Verarbeitung (das Skript noch damit beschäftigt ist - und NO ist es nicht der nächste geplante Lauf ^^) eine zweite Nachricht geöffnet und eine weitere Instanz des gleichen Skripts wird ausgeführt, und eine andere, und eine andere ... in genau 5 Minuten Intervallen.

Ich vermute, irgendwie wird die Nachricht nicht aus der Warteschlange entfernt (obwohl ich dafür gesorgt habe, dass das Skript den Status 200 zurücksendet), was zu einer neuen Nachricht führt, wenn das Skript zu lange läuft.

Gibt es eine Möglichkeit, das Entstehen einer anderen Nachricht zu verhindern? Sagen Sie der Warteschlange oder dem sqs-Daemon, keine neuen Flugnachrichten zu erstellen. Muss ich die Nachricht in meinem Code entfernen? Obwohl das Tutorial besagt, dass es automatisch passieren sollte

Ich möchte nur das Skript auslösen, entfernen Sie die Nachricht aus der Warteschlange und lassen Sie das Skript ausgeführt werden. Keine ausgefallenen Fallback/Retry-Mechanismen bitte :-)

Ich verbrachte viele Stunden damit, etwas im Internet zu finden. Erfolglos. Jede Hilfe wird geschätzt.

Dank

Antwort

1

eine zweite Nachricht geöffnet wird und eine andere Instanz des gleichen Skript ausgeführt wird, und ein anderer, und ein anderer ... in genau 5-Minuten-Takt.

Ich bezweifle, dass es eine zweite Nachricht ist. Ich glaube, es ist die gleiche Nachricht.

Wenn Sie nicht mit 200 OK antworten, bevor das Zeitlimit für Inaktivität abgelaufen ist, wird die Nachricht in die Warteschlange zurückgeleitet, und Sie erhalten es erneut, da das System davon ausgeht, dass Sie abgestürzt sind um es wieder zu sehen. Das ist Teil des Designs.

Es gibt einen X-Aws-Sqsd-Receive-Count Anforderungskopf, den Sie erhalten, der Ihnen ungefähr mitteilt, wie oft die aktuelle Nachricht zugestellt wurde. Der Anforderungsheader X-Aws-Sqsd-Msgid identifiziert die eindeutige Nachricht.

Wenn Sie nicht sicherstellen können, dass das Skript vor dem Timeout abgeschlossen wird, ist dies wahrscheinlich kein geeigneter Anwendungsfall für diesen Dienst.Es klingt wie der Dienst ordnungsgemäß funktioniert.

+0

Hey Michael, danke für die Antwort. Du hast recht. Es ist die gleiche Nachricht. Ich sende 200 wie hier beschrieben [link] (http://stackoverflow.com/questions/15273570/continue-processing-php-after-sending-http-response) aber es täuscht den Daemon nicht. Ich werde ein bisschen mehr damit experimentieren. Falls ich 200 nicht schnell genug senden kann - gibt es eine Möglichkeit, das Inaktivitäts-Timeout zu verlängern oder zu verhindern, dass die Warteschlange die Nachricht erneut hervorbringt? – Jarek

0

Details zu den konfigurierbaren Werten finden Sie unter the Worker Environment documentation. Sie können mehrere verschiedene Zeitüberschreitungswerte sowie "Max. Wiederholungen" konfigurieren, die, wenn sie auf 1 gesetzt sind, das erneute Senden verhindern. Ihre Warteschlange für unzustellbare Nachrichten füllt sich jedoch mit Nachrichten, die tatsächlich erfolgreich verarbeitet wurden, sodass dies möglicherweise nicht Ihre beste Option ist.

Verwandte Themen