第284章 単純な JMS バッチコンポーネント
Camel バージョン 2.16 から利用可能
SJMS Batch は、JMS キューからパフォーマンスの高いトランザクションバッチ消費のための特殊なコンポーネントです。コンシューマーのみのコンポーネントおよびアグリゲーターのハイブリッドとして考えることができます。
Camel の一般的なユースケースは、キューからメッセージを消費し、集約された状態を別のエンドポイントに送信する前に集約することです。処理を実行しているシステムが失敗した場合にデータが失われないようにするため、通常はキューからのトランザクション内で消費され、JDBC コンポーネントで見つかったものなどの永続 AggregationRepository に保存されている集約が集約されます。
Aggregator パターンの動作は、受信メッセージが集約される前に AggregationRepository からデータを取得し、後で結果を書き込む必要があります。実際、集約されたアーティファクトの数が増えると、読み取りおよび書き込みが徐々に遅くなります。この影響を示す任意の時間単位を使用した例は次のとおりです。
| 項目 | 読み取り時間 | 書き込み時間 | 合計時間 |
|---|---|---|---|
| 0 | 0 | 1 | 1 |
| 1 | 1 | 2 | 4 |
| 2 | 2 | 3 | 9 |
| 3 | 3 | 4 | 16 |
| 4 | 4 | 5 | 25 |
| 5 | 5 | 6 | 36 |
| 6 | 6 | 7 | 49 |
| 7 | 7 | 8 | 64 |
| 8 | 8 | 9 | 81 |
| 9 | 9 | 10 | 100 |
一方、SJMS Batch コンポーネントを使用した消費パフォーマンスはリニアです。各メッセージは、次のメッセージがフェッチされる前に AggregationStrategy を使用して消費され、集計されます。すべての消費と集約が単一の JMS トランザクションで実行されるので、中間状態を永続化するために外部ストレージは必要ありません。上記の読み取りおよび書き込みコストを回避します。実際には、これにより、スループットが増加する複数の順序が高くなります。
最初のメッセージ以降のサイズまたは期間のいずれかで完了条件が満たされると、集約された Exchange はルートに渡されます。このエクスチェンジの処理中に、例外がスローされた場合やシステムがシャットダウンすると、元の消費されたメッセージがすべてキューに戻されます（または、ブローカー設定に応じてデッドレターキューに置かれます）。
通常のアグリゲーターとは異なり、集約条件のファシリティーはありません。つまり、メッセージの複数のグループに消費をバッチ処理することはできません。消費されるすべてのメッセージは単一のバッチに集約されます。
複数の JMS コンシューマーサポートが利用できます。これにより、1 つのルートを使用して並行して消費でき、同時に JMS メッセージグループなどの機能を使用して関連メッセージをグループ化できます。
Maven ユーザーは、このコンポーネントの pom.xml に以下の依存関係を追加する必要があります。
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-sjms</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>284.1. URI 形式
sjms:[queue:]destinationName[?options]
destinationName は JMS キューです。デフォルトでは、destinationName はキュー名として解釈されます。
sjms:FOO.BAR
必要に応じて、オプションの queue: プレフィックスを含めることができます。
sjms:queue:FOO.BAR
トピック消費は、そのコンテキスト内でバッチ消費を使用する利点がないため、サポートされていません。通常、トピックメッセージは永続的ではなく、損失は許容されます。失敗したトランザクション内で消費されると、トピックメッセージはブローカーによって再配信されない可能性があります。単純な SJMS コンシューマーエンドポイントは、このシナリオの通常の非永続性アグリゲーターと併用できます。
