[
https://issues.apache.org/jira/browse/CAMEL-24928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24928.
---------------------------------
Fix Version/s: 4.23.0
Resolution: Fixed
The fix is merged on main, so it is in Camel 4.23.0:
* 79100049c220 CAMEL-24928: camel-core - Throttle EIP with asyncDelayed should
not fail with NullPointerException when no permit is que
Resolving, as the ticket was not updated when the PR was merged.
_Claude Code on behalf of Claus Ibsen_
> Throttle EIP with asyncDelayed fails with NullPointerException when the
> maximum requests is 0
> ---------------------------------------------------------------------------------------------
>
> Key: CAMEL-24928
> URL: https://issues.apache.org/jira/browse/CAMEL-24928
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> A throttle whose maximum requests evaluates to 0 is accepted (only negative
> values are rejected). In three of the four modes such an exchange waits until
> the rate is raised. In the default (total requests) mode with
> {{asyncDelayed()}} it fails instead:
> {code:java}
> from("direct:start").throttle(0).asyncDelayed().to("mock:result");
> {code}
> {noformat}
> throttle(0) sync -> no completion after 3s (waits)
> throttle(0) asyncDelayed -> completed,
> exception=java.lang.NullPointerException: Cannot invoke
> "...ThrottlePermit.getDelay(...)" because the return value of
> "...ThrottlingState.peek()" is null
> throttle(0) concurrent-sync -> no completion after 3s (waits)
> throttle(0) concurrent-asyncDelayed -> no completion after 3s (waits)
> {noformat}
> This is realistic with header-driven throttling, for example
> {{throttle(header("rate"))}} with {{0}} used to pause a flow.
> Cause: {{TotalRequestsThrottler.processAsynchronously}} schedules the
> exchange with {{throttlingState.peek().getDelay(...)}}. {{peek()}} returns
> {{null}} when the delay queue holds no permit. That is always the case when
> the rate is 0, and (from reading the code, not reproduced) can also happen
> briefly with a positive rate when concurrent exchanges have just polled all
> permits and not yet put them back ({{poll()}} and {{enqueue()}} are separate
> steps).
> Proposed fix: when {{peek()}} returns {{null}}, schedule the exchange to try
> again after one time period instead of dereferencing it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
