Child pages
  • Route Throttling Example
Skip to end of metadata
Go to start of metadata

Route Throttling Example

Available as of Camel 2.1


This example shows how to use the new feature RoutePolicy to dynamically at runtime to throttle routes based on metrics gathered by the current number of inflight exchanges.

What it means is that Camel will dynamic throttle the routes based on the flow of messages being processed at runtime.

The example have 3 routes where as two of the routes are input routes, and the last is the processing route
1. route1: from("jms") - input from a JMS queue
2. route2: from("file") - input from a file folder
3. route3: from("seda") - processing of the input messages, this one simulates CPU work by delaying the messages 100 mills.

How it works

When the example runs we have a dependency from the routes as follows:

  • route1 -> route3
  • route2 -> route3

What the example demonstrates is that Camel is capable of dynamic throttling route1 and route2 based on the total flow of messages. At runtime Camel gathers the current inflight exchanges in a registry which is used for metrics.

So when the flow is going too fast then the RoutePolicy kicks in and suspends route1 and/or route2. The current inflight exchanges will continue to be processed and when we are below a threshold then the RoutePolicy kicks in again and resumes route1 and/or route2.

Camel provides the throttling policy in the org.apache.camel.impl.ThrottlingInflightRoutePolicy.

How to run

The example has 3 maven goals to run the example

mvn compile exec:java -PCamelServer - starts the Camel Server which contains the 3 routes and where you should check its log output for how it goes.

mvn compile exec:java -PCamelClient - is a client that sends 10000 JMS messages to the JMS broker which is consumed by route1. The Server must be started beforehand.

mvn compile exec:java -PCamelFileClient - is a client that creates 5000 files that are consumed by route2. The server may be started beforehand, but its not required.

So at first you start the server. Then at any time you can run a client at will. For example you can run the JMS client and let it run to completion at the server. You can see at the server console logging that it reports the progress. And at sometime it will reach 10000 messages processed. You can then start the client again if you like.

You can also start the other client to create the files which then let the example be a bit more complicated as we have concurrent processing of JMS messages and files at the same time. And where as both of these should be dynamic throttled so we wont go too fast.

How to change

You can check the file src/main/resources/META-INF/spring/camel-server.xml file where you can see the configuration of the dynamic throttler. By default its configured as:

You can then change this and restart the server to see the changes in effect.

JMX management

At runtime you can manage the ThrottlingInflightRoutePolicy at runtime as its listed under services in the JConsole.
For example you can change the option maxInflightExchanges while its running to find a more suitable value.

The screenshot below illustrates it from a JConsole.

See more at using JMX with Camel.

Sample output from running example

When running the example you should see a lot of activity logged to the console.
Below is a snippet when the example runs to an end when the 10000 messages have been processed. What you should notice is that the throttling ensures that the JMS consumer is not taking in more messages than we can process. That means that ++JMS++ and ++SEDA++ are completing at nearly the same time.

However if you run the example without the throttling you will notice that the JMS consumer runs faster than we can process the messages. Towards the end we have more than 2000 messages pending on the internal SEDA queue, when the JMS consumer finishes.

So by using the ThrottlingInflightRoutePolicy we can throttle the intake of messages to be on a pair with the speed we can process messages. And since its pluggable you can implement your own custom logic to throttle according to your needs.

See Also

  • No labels