[
https://issues.apache.org/jira/browse/CAMEL-25109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-25109.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/27015
> 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
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.23.0
>
>
> 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)