danilop / danilop/SampleBatchProcessing

Alarm sounding before message deleted

Open
#3 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
48
Forks
8
PR merge metrics
No merged PRs in 30d

Description

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?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.