[
https://issues.apache.org/jira/browse/CAMEL-26755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26755 started by shashank.
----------------------------------------
> camel-support - AbstractCamelClusterService: a view whose start fails keeps
> its reference, so it is never started again and never stopped
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26755
> URL: https://issues.apache.org/jira/browse/CAMEL-26755
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> {{AbstractCamelClusterService.getView}} takes a reference on the view of the
> namespace and starts the view on the first reference. The reference count is
> increased before the view is started, and nothing gives it back when the
> start throws. The caller gets the exception and holds no reference, but the
> count stays at 1:
> * the next {{getView}} only increases the count, so the view is not started:
> a {{master:}} route started again (by an operator or the supervising route
> controller) is reported started but the node never takes part in the
> election, also as the only node and after the cause of the failure is gone; a
> clustered route added later on the same namespace is never started either;
> * {{releaseView}} can no longer bring the count to 0, so the view is never
> stopped;
> * after the cluster service is stopped and started again (CamelContext
> restart, or the JMX operations), it starts every view with references,
> including this one that no route uses, so the node can take the leadership of
> a namespace it does not use and the route of the other nodes never runs (what
> CAMEL-25089 and CAMEL-26577 made sure does not happen for released views).
> A view start can fail when the backend is not reachable yet (for example
> {{ConsulClusterView}} creates a session, {{JGroupsRaftClusterView}} connects,
> {{InfinispanRemoteClusterView}} writes to the remote cache), or on an invalid
> setting ({{FileLockClusterView}} rejects an {{acquireLockInterval}} below 1
> millisecond).
> Expected: when the view cannot be started, the reference is given back, so
> the next {{getView}} starts the view again, and the reference count matches
> the users of the view.
> Suggested fix: in the view holder, give the reference back (without changing
> anything else) when the start throws, and rethrow.
> Found with Specula (TLA+ model checked against traces of the real code) and
> confirmed with a test on the real classes.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
