[
https://issues.apache.org/jira/browse/CAMEL-26756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26756:
--------------------------------
Fix Version/s: 4.24.0
> camel-cluster - ClusteredRouteController stops the cluster service before the
> routes have stopped, so another node can take over while exchanges are still
> in flight
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26756
> URL: https://issues.apache.org/jira/browse/CAMEL-26756
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> When the CamelContext stops, it stops its route controller first, and then
> the routes, with the shutdown strategy waiting for the in-flight exchanges
> (45 seconds by default). {{ClusteredRouteController.doStop}} stops the
> cluster service. Stopping the service stops its views, which gives up the
> leadership (for example the file lock is released, the Kubernetes lease is no
> longer renewed).
> So when the leader is stopped gracefully (a rolling restart, a redeploy)
> while it still has in-flight exchanges, another node can become the leader
> (on its next lock attempt, or once the lease expires) and start the clustered
> routes while this node still processes them, and its consumers may still take
> new messages until they are stopped. For a JMS or file consumer this means
> two nodes consume at the same time, which the clustered route controller is
> used to avoid.
> A cluster service that is a service of the CamelContext (the usual setup, and
> the only one the controller looks up) is also stopped by the CamelContext
> itself, after the routes. A cluster service set on the controller with
> {{setClusterService}} is started by the controller, so it must still be
> stopped by it.
> With the file lock cluster service, a stopped view also signals the
> leadership as lost (CAMEL-25089); the clustered route policy ignores it while
> the CamelContext stops, but the lock is free for the other nodes.
> Expected: the cluster service keeps the leadership until the routes have
> stopped, and is stopped then.
> Suggested fix: when the CamelContext is stopping, the controller does not
> stop the cluster service in {{doStop}}, and stops it once the routes have
> stopped ({{CamelContextRoutesStoppedEvent}}). A controller stopped on its own
> still stops the service right away.
> Found in a code review of the cluster 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)
