2016-03-19 2 views
1

私は、Camelルートで実装されたサービスをActiveMQキューから消費し、処理して外部システムに送信します。Camel:エラー状態が解決されるまでActiveMQメッセージを延期する

外部システムの呼び出し中に何か問題が発生した場合、メッセージIDはコールバックエンドシステムに通知されなければなりません。メッセージの順序を維持する必要があるため、サービスは、エラー状態が解決されるまで、すでにエンキューされているメッセージと次のメッセージを遅延させる必要があります。

実際、失敗したメッセージは処理されているためキューから削除する必要があり、失敗する可能性があります。これは、Camelの再配信と比較して異なる可能性があります。

バックエンドシステムは、それ以降のプロセスを制御するものとします。問題のメッセージを再度送信すると、サービスはこの1つのメッセージ(IDで識別される)を処理し、遅延したメッセージを処理し続ける必要があります。または、バックエンドは、遅延メッセージの処理を続行するためにサービスに信号を送る継続信号を送信しますが、失敗したメッセージは再び表示されませんでした。どちらのオプションもエラー状態を解決します。

これまでのところ、私はそれが直接、または処理するために延期するものがある場合は、着信メッセージを処理できる場合、ルートが決定した複数のキューを含むキャメルベースのスイッチング、のいくつかの並べ替えを実装すると考えてきました。しかし、このシナリオをすっきりと描写するEIPがあるかどうかはわかりません。

キャメルアプローチで私に助言を与えることができますか?

答えて

1

オーケストレーションされたワークフローと1つのEIP-b/cのように(少なくとも私にとっては)、あなたは複数のステップにわたって状態を維持する必要性を説明しています。これは、イベント駆動型システムでは完全に行うことができますが、通常は1つのキューソリューションと1つのEIPだけを使用しようとすると、脆弱になります。

複数キュー/複数ラクダ経路アプローチは、私の知る限りとして

0

おそらく、再試行された交換の優先度を設定するためにResequencer EIPを使用することができます:http://camel.apache.org/resequencer.html

+0

等、一般メッセージの順序を維持する(ETC経路、再キューイングすべてを、停止)任意不自然な行為を必要とするストレートフォワードとしないであろうResequencerを理解する、それは私の特定の問題のための選択肢ではない。失敗状態になると、入力キューは未知数の着信メッセージによって増加する可能性があります。 Resequencerは、サイズ制限されたバッチまたはタイムアウトを待ちます。たぶん、バックエンドは数日後に継続信号を送信します。シーケンス外のメッセージの配信は許可されません。 – mdo

関連する問題