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
How it works
When the example runs we have a dependency from the routes as follows:
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
Camel provides the throttling policy in the
How to run
The example has 3 maven goals to run the example
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
You can then change this and restart the server to see the changes in effect.
At runtime you can manage the
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.
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