Aggregate

Usage

The Aggregate pattern uses an expression to determine which messages to aggregate into a single message. Messages that match the expression are held until they are combined by the specified aggregation strategy bean.

The Aggregate pattern can be placed anywhere in the body of a route.

Properties

Table 34, “Aggregate Properties” describes the properties you can specify using the properties editor.

Table 34. Aggregate Properties

Name	Description
`language`	Specifies the expression language used to process the correlation expression.
`Aggregate Controller Ref`	Specifies a reference to a org.apache.camel.processor.aggregate.AggregateController to allow external sources to control this aggregator.
`Aggregation Repository Ref`	Specifies a reference for looking up a custom AggregationRepository in the registry. The AggregationRepository stores the messages while they are being aggregated (held).
`Close Correlation Key On Completion`	Specifies the number of closed correlation keys stored in the cache used to determine if an exchange should be accepted.
`Complete All on Stop`	Indicates to wait to complete all current and partial (pending) aggregate exchanges when the context is stopped. When enabled, the aggregate will wait to complete all exchanges before it is stopped, when the Camel context or the route using it is stopped.
`Completion From Batch Consumer`	Specifies whether aggregates can be completed based on information from a batch consumer. The default is Disabled.
`Completion Interval`	Specifies an interval of time, in milliseconds, after which the aggregator completes any in process aggregate messages. This property cannot be used with `Completion Timeout`.
`language`	Specifies the expression language used to process the completion size expression.
`Completion Size`	Specifies an expression used to determine when aggregation is complete based on the number of exchanges processed.
`Completion Timeout`	Specifies an expression used to determine when aggregation is complete based on the amount of time, in milliseconds, the aggregator has been inactive.
`Description`	Specifies a text description for the node. This description is included in the generated XML file, but it is informational only. It is not used by Apache Camel.
`Discard On Completion Timeout`	Specifies whether aggregates that are completed due to a timeout, in milliseconds, are discarded. The default is Disabled.
`Eager Check Completion`	Specifies whether the aggregator determines completion by eagerly checking the data as exchanges are received or by checking the data after it’s been aggregated into a single exchange. The default is Disabled. This property works in conjunction with and influences the behavior of the `Completion Predicate` property.
`Executor Service Ref`	Specifies a reference for looking up the executorService to use for thread pool management when using the `Parallel Processing` option or when sending out aggregated exchanges.
`Force Completion On Stop`	Specifies whether to complete all aggregated exchanges currently in route when the routing context is stopped. The default is Disabled.
`Group Exchanges`	Specifies whether the aggregator groups all outgoing exchanges into a single `GroupedExchange` object. The default is Disabled.
`Id`	Specifies a unique identifier for the endpoint. The tooling automatically generates an id for a node when it is created, but you can remove that id or replace it with your own. The Camel debugger requires all nodes with a breakpoint set to have a unique id. You can use the id to refer to endpoints in your Camel XML file.
`Ignore Invalid Correlation Keys`	Specifies whether the aggregator ignores invalid correlation keys. The default is Disabled, which causes the aggregator to throw an exception when it encounters an invalid correlation key.
`Optimistic Lock Retry Policy`	Configures the retry settings when Optimized locking is enabled. See Table 35, “Optimistic Lock Retry Configuration Options” for configuration details.
`Optimistic Locking`	Specifies whether to use optimistic locking when aggregating messages. When enabled, the AggregationRepository (see [AggRepo] must support optimistic locking (which all out-of-the-box, camel-supplied aggregation repositories do). The default is Disabled.
`Parallel Processing`	Specifies whether the aggregator processes multiple messages concurrently. The default is Disabled.
`Strategy Method Allow Null`	Specifies whether the aggregate method is used on the initial aggregation. When disabled, it is not used on the initial aggregation. When enabled, null values are used as the `oldExchange` (on the initial aggregation) when POJOs are used as the AggregationStrategy. The default is Disabled.
`Strategy Method Name`	Explicitly specifies the name of the method to use when using POJOs as the AggregationStrategy.
`Strategy Ref`	Specifies a reference for looking up the AggregationStrategy in the registry.
`Timeout Checker Executor Service Ref`	Specifies a reference for looking up the timeoutExecutorService to use for custom thread pool management when using one of the options: `Completion Timeout`, `Completion Timeout Expression`, or `Completion Interval`.

Table 35, “Optimistic Lock Retry Configuration Options” describes the properties used to configure how a failed optimized lock is tried.

Table 35. Optimistic Lock Retry Configuration Options

Name	Default	Description
`Exponential Back Off`	Enabled	Enables/disables exponential back off mode, which uses an exponential algorithm to calculate successive retry intervals after `Retry Delay`, not to exceed `Maximum Retry Delay`.
`Maximum Retries`	0	Specifies the maximum number of retries that will be attempted. When reached, no further attempt will be made.
`Maximum Retry Delay`	0 ms	Specifies the maximum wait time, in milliseconds, between retries.
`Random Back Off`	Disabled	Enables/disables random back off mode, which uses random number generation to calculate successive retry intervals after `Retry Delay`, not to exceed `Maximum Retry Delay`.
`Retry Delay`	50 ms	Specifies the initial wait time interval, in milliseconds, between retries.

Combining retry configuration options has these effects:

When Random Back Off is enabled, Retry Delay is ignored.
When Random Back Off is enabled, but Maximum Retry Delay is not, Maximum Retry Delay defaults to 1000 ms, and the random back off delay will be between 0 and 1000 ms.
When Exponential Back Off is enabled and Maximum Retry Delay set, the Retry Delay keeps doubling in value until it reaches or exceeds Maximum Retry Delay. At that point, the value of Maximum Retry Delay is used as the Retry Delay.
When both Exponential Back Off and Random Back Off are enabled, Exponential Back Off takes precedence.
When both Exponential Back Off and Random Back Off are disabled, the value of Retry Delay is used and remains constant throughout all retry attempts.

Aggregate

Usage

Properties

Related topics