[
https://issues.apache.org/jira/browse/CAMEL-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029142#comment-15029142
]
Aaron Whiteside commented on CAMEL-9355:
----------------------------------------
You are right, there is an extra thread per throttler to release the permits,
we could make this shared, but then we would need to size the pool size
correctly to handle any number of throttles using it.
There is actually no re-queuing happening, if a permit cannot be obtained and
isAsyncDelayed() is enabled then the exchange is queued, the async executor
thread pool will process the exchange's FIFO making the "async" requests block
just like any normal thread calling the throttler with isAsyncDelayed()
disabled. If you turn on TRACE logging you'll see how much time a exchange
spent being queued vs blocking for a permit. But definitely async exchange's
are not retried in any sort of loop.
> Current Throttler implementation is not accurate and does not work in a
> multi-threaded route
> --------------------------------------------------------------------------------------------
>
> Key: CAMEL-9355
> URL: https://issues.apache.org/jira/browse/CAMEL-9355
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 2.16.0
> Reporter: Aaron Whiteside
> Attachments: CAMEL_9355.patch
>
>
> Current Throttler implementation is not accurate and is even more inaccurate
> in a multi-threaded route (think sjms....consumerCount=100).
> The delay to sleep cannot be calculated ahead of time in a multi-threaded
> environment, to this end the Throttler should not extend
> DelayProcessorSupport.
> Attached is a patch that changes throttler to use a Semaphore to do accurate
> and multi-thread safe throttling.
> The code I think is much cleaner, smaller and easier to understand. Than it
> used to be before.
> Unit tests still pass, I had to make some changes to ThrottlerTest as it made
> assumptions about the implementation and was doing bad things like adding a
> 750ms buffer to validating the minimum throttle delay.. ThrottlerTest is now
> very sane.
> I've also implemented support to allow the throttler construct to be used
> without any nested outputs. For example the follow code is now valid.
> {code}
> <throttle><constant>100</constant></throttle>
> {code}
> If you want to disable this feature it can be done in
> ThrottlerDefinition::createProcessor() line 82 changing false to true.
> I think this allows more flexible usage of the throttler, in my use case I
> want to delay the further execution of the route, and I don't want to have to
> split my routes up into separate sub-routes to be able to do that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
