Hey there, I did some more testing and debugging. I think there are two problems.
One is with the implementation of Throttler.nextSlot(). In there a new slot is generated whenever a slot is full or not in the current timeframe. Whenever the throttling rate changes from a low to a high number this will create a problem. As the capacity of the last frame will be reached, with still time left in the frame a new slot will be created one time period into the future. If the next message arrives before the current time has slid into this timeslot, another new slot even further in the future will be created. This is a tricky situation, which can be recovered from, but it can also lead to a system sticking to a rate of 1 per timeframe, especially when new messages keep pouring in. I suggest introducing a new method in TimeSlot, isPast(), which will only check if the slot is already in the past. This fixed a test when changing from low to high rate for me. The second problem occurs when changing from a high to a low rate. The current slot capacity is not affected when the rate changes. This means that the route will throttle using the old rate until the current slot is full. This may or may not be acceptable. I tried several things, but got the best result by setting the slot.capacity to 0 in the if clause where maximumRequestsPerPeriod is set to the new value. This will force a new slot to be created for the message. This seems unneccesary hacky to me, but in light of the race conditions that occur at that point it seemed the best solution to me. Perhaps someone will come up with something cleaner =) I created a new test for ThrottlerTest to test dynamically changing rates in headers: Should I open a bug report for this? Cheers, Michael -- View this message in context: http://camel.465427.n5.nabble.com/Problems-with-dynamic-throttling-tp5746613p5746661.html Sent from the Camel - Users mailing list archive at Nabble.com.
