...
![]() Wiki Markup |
{div:class=confluenceTableSmall}
|| Name || Default Value || Description ||
| {{strategyRef}} | | Refers to an [AggregationStrategy|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/aggregate/AggregationStrategy.html] to be used to assemble the replies from the multicasts, into a single outgoing message from the [Multicast]. By default Camel will use the last reply as the outgoing message. From *Camel 2.12* onwards you can also use a POJO as the {{AggregationStrategy}}, see the [Aggregate|Aggregator2] page for more details. |
| {{strategyMethodName}} | | *Camel 2.12:* This option can be used to explicit declare the method name to use, when using POJOs as the {{AggregationStrategy}}. See the [Aggregate|Aggregator2] page for more details. |
| {{strategyMethodAllowNull}} | {{false}} | *Camel 2.12:* If this option is {{false}} then the aggregate method is not used if there was no data to enrich. If this option is {{true}} then {{null}} values is used as the {{oldExchange}} (when no data to enrich), when using POJOs as the {{AggregationStrategy}}. See the [Aggregate|Aggregator2] page for more details. |
| {{parallelProcessing}} | {{false}} | If enablesenabled then sending messages to the multicasts occurs concurrently. Note the caller thread will still wait until all messages has been fully processed, before it continues. Its only the sending and processing the replies from the multicasts which happens concurrently. |
| {{parallelAggregate}} | {{false}} | *Camel 2.14:* If enabled then the {{aggregate}} method on {{AggregationStrategy}} can be called concurrently. Notice that this would require the implementation of {{AggregationStrategy}} to be implemented as thread-safe. By default this is {{false}} meaning that Camel synchronizes the call to the {{aggregate}} method. Though in some use-cases this can be used to archive higher performance when the {{AggregationStrategy}} is implemented as thread-safe. |
| {{executorServiceRef}} | | Refers to a custom [Thread Pool|Threading Model] to be used for parallel processing. Notice if you set this option, then parallel processing is automatic implied, and you do not have to enable that option as well. |
| {{stopOnException}} | {{false}} | *Camel 2.2:* Whether or not to stop continue processing immediately when an exception occurred. If disable, then Camel will send the message to all multicasts regardless if one of them failed. You can deal with exceptions in the [AggregationStrategy|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/aggregate/AggregationStrategy.html] class where you have full control how to handle that. |
| {{streaming}} | {{false}} | If enabled then Camel will process replies out-of-order, eg in the order they come back. If disabled, Camel will process replies in the same order as multicasted. |
| {{timeout}} | | *Camel 2.5:* Sets a total timeout specified in millis. If the [Multicast] hasn't been able to send and process all replies within the given timeframe, then the timeout triggers and the [Multicast] breaks out and continues. Notice if you provide a [TimeoutAwareAggregationStrategy|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/aggregate/TimeoutAwareAggregationStrategy.html] then the {{timeout}} method is invoked before breaking out. If the timeout is reached with running tasks still remaining, certain tasks for which it is difficult for Camel to shut down in a graceful manner may continue to run. So use this option with a bit of care. We may be able to improve this functionality in future Camel releases. |
| {{onPrepareRef}} | | *Camel 2.8:* Refers to a custom [Processor] to prepare the copy of the [Exchange] each multicast will receive. This allows you to do any custom logic, such as deep-cloning the message payload if that's needed etc. |
| {{shareUnitOfWork}} | {{false}} | *Camel 2.8:* Whether the unit of work should be shared. See the same option on [Splitter] for more details. |
{div} |
...
By default Multicast invokes each endpoint sequentially. If parallel processing is desired, simply use
![]() Code Block |
from("direct:a").multicast().parallelProcessing().to("direct:x", "direct:y", "direct:z");
|
In case of using InOut MEP, an AggregationStrategy is used for aggregating all reply messages. The default is to only use the latest reply message and discard any earlier replies. The aggregation strategy is configurable:
![]() Code Block |
from("direct:start")
.multicast(new MyAggregationStrategy())
.parallelProcessing().timeout(500).to("direct:a", "direct:b", "direct:c")
.end()
.to("mock:result");
|
...
But sometimes you just want Camel to stop and let the exception be propagated back, and let the Camel error handler handle it. You can do this in Camel 2.1 by specifying that it should stop in case of an exception occurred. This is done by the stopOnException option as shown below:
![]() Code Block |
from("direct:start")
.multicast()
.stopOnException().to("direct:foo", "direct:bar", "direct:baz")
.end()
.to("mock:result");
from("direct:foo").to("mock:foo");
from("direct:bar").process(new MyProcessor()).to("mock:bar");
from("direct:baz").to("mock:baz");
|
And using XML DSL you specify it as follows:
![]() Code Block |
|
|
<route>
<from uri="direct:start"/>
<multicast stopOnException="true">
<to uri="direct:foo"/>
<to uri="direct:bar"/>
<to uri="direct:baz"/>
</multicast>
<to uri="mock:result"/>
</route>
<route>
<from uri="direct:foo"/>
<to uri="mock:foo"/>
</route>
<route>
<from uri="direct:bar"/>
<process ref="myProcessor"/>
<to uri="mock:bar"/>
</route>
<route>
<from uri="direct:baz"/>
<to uri="mock:baz"/>
</route>
|
...
Notice the onPrepare option is also available on other EIPs such as Splitter, Recipient List, and Wire Tap.
![]() Include Page |
|
|
