Throttler - 6.3

Talend ESB Mediation Developer Guide

Talend Data Fabric
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Open Studio for ESB
Talend Real-Time Big Data Platform
Design and Development
Talend ESB

The Throttler Pattern allows you to ensure that a specific endpoint does not get overloaded, or that we don't exceed an agreed SLA with some external service.



Default Value


maximumRequestsPerPeriod Maximum number of requests per period to throttle. This option must be provided as a positive number. Note, in the XML DSL, this option is configured using an Expression instead of an attribute.
timePeriodMillis1000The time period in milliseconds, in which the throttler will allow at most maximumRequestsPerPeriod number of messages.
asyncDelayedfalseIf enabled then any messages which is delayed happens asynchronously using a scheduled thread pool.
executorServiceRef Refers to a custom Thread Pool to be used if asyncDelay has been enabled.
callerRunsWhenRejectedtrueIs used if asyncDelayed was enabled. This controls if the caller thread should execute the task if the thread pool rejected the task.

Camel 2.14: If this option is true, throttler throws a ThrottlerRejectExecutionException when the request rate exceeds the limit.

Using the Fluent Builders


The above example will throttle messages all messages received on seda:a before being sent to mock:result ensuring that a maximum of 3 messages are sent in any 10 second window. Note that since timePeriodMillis defaults to 1000 milliseconds, just setting the maximumRequestsPerPeriod has the effect of setting the maximum number of requests per second. So to throttle requests at 100 requests per second between two endpoints, it would look more like this...


For further examples of this pattern in use see this JUnit test case.

Using the Spring XML Extensions

   <from uri="seda:a" />
   <throttle timePeriodMillis="10000"/>
      <to uri="mock:result" />

You can let the Throttler use non-blocking asynchronous delaying, which means Camel will use a scheduler to schedule a task to be executed in the future. The task will then continue routing. This allows the caller thread to not block and be able to service other messages etc.