SJMS Batch Component
Available as of Camel 2.16
SJMS Batch is a specialized component for highly performant, transactional batch consumption from a JMS queue. It can be thought of as a hybrid of a consumer-only component and an aggregator.
A common use case in Camel is to consume messages from a queue and aggregate them before sending the aggregated state to another endpoint. In order to ensure that data is not lost if the system performing the processing fails, it is typically consumed within a transaction from the queue, and once aggregated stored in a persistent AggregationRepository
, such as the one found in Camel JDBC.
The behavior of the aggregator pattern involves fetching data from the AggregationRepository
before an incoming message is aggregated, and writing back the result afterwards. By nature, the reads and writes take progressively longer as the number of aggregated artifacts increases. A rough example of this using arbitrary time units that demonstrates the impact of this is as follows:
Item | Read Time | Write Time | Total Time |
---|---|---|---|
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 |
In contrast, consumption performance using the SJMS Batch component is linear. Each message is consumed and aggregated using an AggregationStrategy
before the next one is fetched. In practice, this yields multiple orders of magnitude higher throughput.
Once a completion condition is met, either by size or period since first message, the aggregated Exchange
is passed into the route. During the processing of this Exchange
, if an exception is thrown or the system shuts down, all of the original consumed messages end up back on the queue (or are placed on the dead-letter queue depending on the broker configuration).
Unlike using a regular aggregator, there is no facility aggregation condition, meaning that it is not possible to batch consume into multiple groups of messages. All consumed messages are aggregated together into a single batch.
Multiple JMS consumer support is available which allows you to consume in parallel using the one route, and at the same time use facilities like JMS message groups to group related messages.
Maven users will need to add the following dependency to their pom.xml
for this component:
<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>
URI format
sjms:[queue:]destinationName[?options]
Where destinationName
is a JMS queue. By default, the destinationName
is interpreted as a queue name.
sjms:FOO.BAR
You can include the optional queue:
prefix, if you prefer:
sjms:queue:FOO.BAR
Topic consumption is not supported, as there is no advantage to using batch consumption within that context. Topic messages are usually non-persistent, and loss is acceptable. If consumed within a transaction that fails, a topic message will likely not be redelivered by the broker.
Component Options and Configurations
The SJMS Batch Component supports the following configuration options:
Option | Required | Default Value | Description |
---|---|---|---|
|
|
| A reference to an |
|
|
| The size of the batch to aggregate. Care should be taken to ensure that this is not larger than the JMS consumer's prefetch buffer, or the maximum page size for a queue on the broker; either of these could cause the consumer to hang if no timeout is used. A value of 0 or less indicates that |
|
|
| The maximum time to wait from the receipt of the first message before emitting the Exchange. A value of 0 or less indicates that |
|
|
| The maximum length of a call to This value is effectively the poll time between batches. |
The completionSize
endpoint attribute is used in conjunction with completionTimeout
, where the first condition to be met will cause the aggregated Exchange
to be emitted down the route.