shashank created CAMEL-24928:
--------------------------------
Summary: 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
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)
