Claus Ibsen created CAMEL-25109:
-----------------------------------
Summary: camel-core - Scheduled poll consumer: fix bugs found in a
deep review
Key: CAMEL-25109
URL: https://issues.apache.org/jira/browse/CAMEL-25109
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: Claus Ibsen
A review of the scheduled poll consumer (ScheduledPollConsumer,
DefaultScheduledPollConsumerScheduler) found these bugs:
# The {{delay}}, {{initialDelay}}, {{timeUnit}} and {{useFixedDelay}} changed
while the consumer is stopped (such as using JMX: stop, setDelay, start) are
ignored when the consumer is started again, as the scheduler created at the
first start is reused with its old settings (while the getter reports the new
value).
# {{repeatCount}} with {{scheduler.concurrentConsumers}} > 1 fails with
ConcurrentModificationException (or NullPointerException), logged as ERROR, as
the concurrent polling threads unschedule the task at the same time and the
list of scheduled futures is not thread-safe.
# A poll that is still running when the consumer is stopped updates the state
(such as first poll done and the counters) after it has been reset, so after a
restart the consumer reports ready before it has polled.
# With {{backoffErrorThreshold}} (or {{backoffIdleThreshold}}) configured but
no {{backoffMultiplier}}, the error counter is reset on every other poll
(operator precedence in the backoff condition), so the error count in the
health check and JMX is wrong.
# When a backoff finishes, the error counter is reset before the next poll, so
the health check reports UP while the consumer is still failing, and the count
starts again at 1.
# The last error details (such as the http response code) are kept for a later
error without details, and the last error is kept after the consumer is stopped.
Not changed:
* The documentation of backoffMultiplier says it is the number of polls
skipped, but N skips N-1 polls (changing it regenerates the documentation of
all the scheduled poll components).
* A scheduler set on ScheduledPollEndpoint using setScheduler is only used when
configureProperties is called afterwards.
* An endpoint level scheduler bean is shared by all the consumers of the
endpoint.
_Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
