完全に消えてしまうとデバッグもできないし、非同期処理、キューイングシステムでのデバッグとか恐ろしく大変そうで原因調査とかしづらいだろうし、だからこそこういう仕組みが用意されてるんだろうね。多分。
墓場を掘り起こすことが可能なのだろうか。
Amazon SQS は、デッドレターキューをサポートしています。このキューは、正常に処理 (消費) できないメッセージの送信先として、他のキュー (ソースキュー) が使用することができます。問題のあるメッセージを分離して、処理が成功しない理由を調べることができるため、デッドレターキューは、アプリケーションやメッセージングシステムのデバッグに役立ちます。
デッドレターキューを使用するメリット
デッドレターキューの主なタスクは、メッセージの失敗を処理することです。デッドレターキューを使用すると、正しく処理できないメッセージを分離して、処理が成功しなかった理由を調べることができるというメリットがあります。
Amazon SQS デッドレターキュー - Amazon Simple Queue Service
落とし穴？
これは、どういうことなのだろうか？
メッセージの送信を無期限に再試行できる状態にしておく必要がある場合は、スタンダード キューと共にデッドレターキューを使用しないでください。たとえば、従属プロセスがアクティブまたは使用可能になるまで待機する必要があるプログラムでは、デッドレターキューを使用しないでください。
ポイズンピルメッセージ？
って何なの？
受信されたが処理できないメッセージ のことみたいだね。
メッセージ数を減らし、システムで ポイズンピルメッセージ (受信されたが処理できないメッセージ) が発生する可能性を抑えるには、デッドレターキューを使用してください。
Original by Github issue
チャットメンバー募集
何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。