danilop / danilop/SampleBatchProcessing

Alarm sounding before message deleted

オープン
#3 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Shell
スター
48
フォーク
8
PR マージ指標
30日以内にマージされた PR はありません

説明

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?

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。