...
Unlike using a regular aggregator, there is no facility for an aggregation condition, meaning that it is not possible to batch consume into multiple groups of messages at the same time. All consumed messages are aggregated together into a single batch. To get around this, a common design approach is to first sort the different groups of messages to be aggregated onto different queues, and batch consume from each one separately.
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.
...
Code Block |
---|
|
<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> |
SJMS Batch is a subcomponent of SJMS, and resides in the same library.
URI format
Code Block |
---|
sjms:[queue:]destinationName[?options]
|
...
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. A plain SJMS consumer endpoint can be used in conjunction with a regular non-persistence backed aggregator in this scenario.
Component Options and Configurations
...
Div |
---|
class | confluenceTableSmall |
---|
|
Option | Required | Default Value | Description |
---|
aggregationStrategy
| ![(tick)](/confluence/s/34gb19/8804/10mvnxf/_/images/icons/emoticons/check.svg) | null
| A reference to an AggregationStrategy in the Camel registry (e.g. #myAggregationStrategy ) | completionSize
| | 200
| 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 completionTimeout only should be used. | completionTimeout
| | 500
| The maximum time to wait from the receipt of the first message before emitting the Exchange. A value of 0 or less indicates that completionSize only should be used. Notice you cannot use both completion timeout and completion interval at the same time, only one can be configured. | completionTimeout | | | Camel 2.17: The completion interval in millis, which causes batches to be completed in a scheduled fixed rate every interval. The batch may be empty if the timeout triggered and there was no messages in the batch. Notice you cannot use both completion timeout and completion interval at the same time, only one can be configured. | sendEmptyMessageWhenIdle | | false | Camel 2.17: If using completion timeout or interval, then the batch may be empty if the timeout triggered and there was no messages in the batch. If this option is true and the batch is empty then an empty message is added to the batch so an empty message is routed. | pollDuration
| | 1000
| The maximum length of a call to MessageConsumer.receive() . The time remaining before timeout takes precedence within a batch. This value is effectively the poll time between batches. | timeoutCheckerExecutorService | | | Camel 2.17: If using the completionInterval option a background thread is created to trigger the completion interval. Set this option to provide a custom thread pool to be used rather than creating a new thread for every consumer. |
|
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.
...