danilop / danilop/SampleBatchProcessing

Alarm sounding before message deleted

Offen
#3 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Shell
Sterne
48
Forks
8
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

I believe this issue is more of a lack of understanding on my part than clarity in the docs. I've configured a batch processing setup similar to this. Here's what has been happening:

1. Message is sent to the queue.
2. Alarm sounds and starts instance.
3. Get_Jobs.py pulls down the message a t=0.
4. The message changes from "Messages Available" to "Messages In Flight".
5. Get_Jobs.py begins processing the message.
6. At t=2, the message is still in "Messages In Flight" and is currently being processed on the EC2 instance but the alarm sounds and kills the EC2 instance.

It looks like the alarm is sounding 2 minutes after the message is no longer available. This would mean any job would need to take less than 2 minutes to complete or it's at risk of being killed by the alarm.

What do I need to change? Ideally, a message is pulled from the queue and added to an instance. That instance isn't killed until two minutes after the message has been deleted, not two minutes after the message is retrieved.

For context, the messages can take anywhere from 4 to 6 hours to process - I've set the visibilitytimeout to 8 hours. Does this mean the cloudwatch alarm has to wait the same amount as the VisibilityTimeout?

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.