All docs This doc

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

The split-aggregate pattern sends an incoming request from the client to several target endpoints simultaneously. Then it combines all the responses from each back-end to a single response, and sends the response back to the client.
This pattern can be implemented in the ESB using the Iterate mediator, Clone mediator and Aggregate mediator. The Iterate mediator splits the message into a number of different messages that are derived from the parent message using Xpath, and sends the messages to target endpoints using the same sequence. The Clone mediator sends the same message to target endpoints using a different target sequences. The Aggregate mediator collects all the response messages and creates one response message.

Split-aggregate use case

The following use case demonstrates the split-aggregate pattern:


Code Block
<soapenv:Envelope xmlns:soapenv="" xmlns:ser="http://services.samples" xmlns:xsd="http://services.samples/xsd">

Tuning the performance

The Iterate, Clone and Aggregate mediators demonstrate high performance due to default threading and memory configuration. The performance of these mediators can be further increased by tuning the following parameters in the <ESB_HOME>/repository/conf/ file:

synapse.threads.core and synapse.threads.max

Iterate and Clone mediators use a thread pool to create new threads when processing messages and sending messages parallelly. You can configure the size of the thread pool by the synapse.threads.core parameter. The number of threads specified via this parameter should be increased as required to balance an increased load. Increasing the value specified for this parameter results in higher performance of the Iterate and Clone mediators. You can specify the maximum number of synapse threads in the pool by the synapse.threads.max parameter.


The keep-alive time for extra threads is in milliseconds. This parameter is applicable only if the Iterate or the Clone mediator is used to handle a high load. You can increase the number of threads specified via this parameter as required to balance an increased load.


You can use this parameter to specify the length of the queue that is used to hold the runnable tasks to be executed by the pool. You can specify a finite value as the queue length by giving any positive number. If this parameter is set to (-1) it means that the task queue length is infinite.
If the queue length is finite there can be situations where requests are rejected when the task queue is full, and all the cores are occupied. If the queue length is infinite, and if some thread locking happens, the server can go out of memory. Therefore, you need to decide on an optimal value based on the actual load.