EIP/Dead Letter Channel - Java EE勉強会

Dead Letter Channel †

メッセージングに固有な例外処理の考え方の1つ。配送できないメッセージの取り扱いには、Dead Letter Channelを使う。

メッセージングシステムで配送できないメッセージがあった場合はどうするか？

内部処理に問題のあるメッセージはInvalid Message Channelに移すが、そもそも配送不能なメッセージはどうするか？
メッセージが配送不能になる理由は様々ある：
- 配送先チャネルの設定に不備があった
- 配送前にチャネルが削除された
- メッセージの有効期限（Message Expiration）が切れた（明示的な有効期限が無くても、あまりに配送に時間がかかる場合も期限切れとなる）
- Selective Consumerのいずれからも選ばれなかった
- メッセージヘッダに不備があった
配送不能メッセージには何らかの対処をする必要がある（放置する -> システムが散らかる、送信側に送り返す -> 送信側は多分受け取れない、削除する -> 送信側は送信できたと思い込んでいるので後々問題になる、等）。

メッセージングシステムで配送できない／すべきでないメッセージがあった場合は、そのメッセージを「配送不能チャネル（Dead Letter Channel）」へ移すようにする。

Dead Letter Channel（DLC）の仕組みはメッセージングシステムの実装によって異なるが、通常、メッセージングシステムのあるマシンごとに1つローカルのDLCを置く。
- ネットワーク上の問題を意識せずに配送不能メッセージをDLCへ配送できるようにするため。
- メッセージが配送不能になった場所と、（場合によって）配送予定先チャネルを記録する。
配送不能（dead）メッセージと無効（invalid）メッセージとの違いは、そもそも配送できなかったもの（ヘッダを評価した結果に基づく）と、配送できたけれども受信側で正常に処理できなかったもの（メッセージ本文／特定ヘッダの評価に基づく）という違い。
- 配送不能かはメッセージングシステムによって自動的に決定されるが、無効かどうかは受信側で明示的に判断しないといけない。
開発者はメッセージングシステムが提供する配達不能メッセージ処理には手を付けられないが、自身で無効メッセージ処理を設計する際に、そこにシステムで判定できないより広範な配達不能メッセージ処理を含めることもできる。

株式トレーディングのシステムでは、取引が時間内（5分以内）に成立するように取引メッセージに有効期限（Message Expiration）を設定する。5分経った取引メッセージはチャネルから取り除かれ、DLCへ配送される。システムは、DLCを監視して、取引が成立しなかったかどうかを判定する。

個人的には、このDLCをどう監視／メンテナンスすべきかという点が大事だと思っている。しかし、Invalid Message Channelの方にはそのチャネルをどう取り扱うべきか（例外処理をどうすべきか）のアドバイスが書かれているが、DLCにはほとんど書かれていない。Invalid Message Channelのやり方に準じろということなのか、それともメッセージングシステムによってマチマチだからお手上げということなのか。