[
https://issues.apache.org/jira/browse/CAMEL-24626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111473#comment-18111473
]
Henrik commented on CAMEL-24626:
--------------------------------
PR at https://github.com/apache/camel/pull/26112
> camel-master: follow-ups to CAMEL-24583 - leadership lock, cancelled task
> registry entries, backoff documentation
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24626
> URL: https://issues.apache.org/jira/browse/CAMEL-24626
> Project: Camel
> Issue Type: Bug
> Components: camel-master, camel-sjms
> Affects Versions: 4.22.0
> Reporter: Henrik
> Priority: Major
>
> Three issues found while fixing CAMEL-24583. None of them is introduced or
> fixed there.
> h3. 1. A cancelled {{BackgroundTask}} stays in the {{TaskManagerRegistry}}
> A task scheduled through {{BackgroundTask.schedule()}} adds itself to the
> {{TaskManagerRegistry}} from its first run, and only a run of the task
> removes it again. A
> caller that cancels the {{Future}} returned by {{schedule()}} therefore
> leaves the entry
> behind for the life of the {{CamelContext}}: the task keeps showing up as an
> internal task,
> and it keeps its container reachable.
> Affects {{camel-sjms}} ({{SimpleMessageListenerContainer.doStop}}) today, and
> {{camel-master}} ({{MasterConsumer}}) since CAMEL-24583.
> *Proposed fix:* a {{cancel()}} operation on {{BackgroundTask}} that
> unschedules the task and
> deregisters it, used by both call sites.
> h3. 2. Lock inversion between the consumer and the cluster view in
> camel-master
> {{MasterConsumer}} guards its leadership state with the {{BaseService}} lock:
> * {{doStop}} holds that lock and then needs the write lock of the view,
> through
> {{CamelClusterView.removeEventListener}}.
> * {{AbstractCamelClusterView}} dispatches events while holding its own read
> lock, and the
> listener of the consumer then needs the {{BaseService}} lock.
> An unlocked {{isRunAllowed()}} fast path in the listener covers the common
> case, but a
> leadership event that passes that check just before a stop acquires the lock
> closes the two
> orders into a deadlock.
> *Proposed fix:* guard the leadership state with a lock of its own, and never
> hold it across a
> call into the view.
> h3. 3. Exhausted start attempts are not documented
> {{backOffMaxAttempts}} defaults to 10 attempts, {{backOffDelay}} apart (5000
> millis). A node
> that uses up its attempts keeps the leadership and consumes nothing until the
> leadership
> changes again. That is the documented intent of the option, and
> {{backOffMaxAttempts=0}}
> already retries for as long as the node is the leader, but neither the
> consequence nor the
> escape hatch is written down anywhere.
> *Proposed fix:* document both in the component documentation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
