私は現在、以前の処理状態からの再開が重要なCamelIntegrationアプリを開発しています。たとえば、停電が発生した場合、以前に処理されたすべてのメッセージが再処理されないことが重要です。処理は、停止前に中断したところから再開する必要があります。
TerracottaやApacheShiroなど、考えられる解決策をいくつか試しました。Apache Camelとの統合に関するドキュメントが不足しているため、どちらを使用するかわかりません。しかし、私はこの2つに決着をつけていません。
使用できる可能性のある代替案に関する提案、または開始するためのチュートリアルへのポインタを探しています。
停止を乗り切ることの難しさは、主に州と、飛行中のメッセージをどうするかということにあります。
通常、ルート内で状態を話している場合、解決策はそれをディスクまたはクラスター内の他のノードにフラッシュすることです。アグリゲーターパターンを例にとると、集約された状態は集約リポジトリに保持されます。デフォルトの実装はメモリ内にあるため、電源が切れると、すべての状態が失われます。ただし、JDBC用の実装や、Hazelcast（軽量のメモリ内データグリッド）を使用した実装など、他の実装もあります。私自身はHazelcastを使用していませんが、JDBCはディスクへの同期書き込みを行います。アグリゲーターパターンを使用すると、中断したところから再開できます。べき等消費についても同様の解決策があります。
飛行中のメッセージに関する2番目の質問は、もう少し複雑で、どこから消費しているかに大きく依存します。Webサービス要求を処理している最中に電源が切れた場合、メッセージを失ったかどうかは重要ですか？ユーザーは単に再試行できます。外部システムへの影響は、トランザクション、またはJDBCべき等リポジトリを使用するべき等コンシューマにラップできます。
メッセージングに基づいて統合を構築している場合は、トランザクション内で消費する必要があります。これにより、サーバーがダウンした場合に、メッセージがブローカーに戻され、別のコンシューマーで再生できるようになります。
seda:またはブロックを使用するときは注意してくださいthreads。これらはメモリ内のキューを使用してスレッド間の交換を渡します。この種のルートを流れるメッセージは、誰かが電源ケーブルをつまずいた場合に失われます。メッセージ損失を許容できず、この種の処理モデルが必要な場合は、2つのルート間のエンドポイントとしてJMSキューを使用することを検討してください（中断したところから確実に再開できるようにトランザクションを使用）。