[ 
https://issues.apache.org/jira/browse/CAMEL-26880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on CAMEL-26880 started by shashank.
----------------------------------------
> camel-cluster - ClusteredRoutePolicy: a leadership change while the 
> CamelContext is suspended is lost after the resume
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-26880
>                 URL: https://issues.apache.org/jira/browse/CAMEL-26880
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Minor
>
> A leadership change that a {{ClusteredRoutePolicy}} gets while the 
> CamelContext is suspended (for example suspended from JMX) is not applied 
> after the resume:
> *Leadership taken while suspended.* The policy starts its routes with 
> {{startRoute}}, which does nothing while the CamelContext is suspended, and 
> records them as started. The resume only resumes the routes that were started 
> before the suspend, so after the resume the leader does not run the routes, 
> and no later change starts them until the leadership changes again.
> *Leadership lost while suspended.* A route whose consumer does not support 
> suspension is stopped by the suspend. The policy then skips it (it is not 
> stoppable) and keeps it recorded as started. The resume starts it again, so a 
> node that is no longer the leader runs the route next to the new leader.
> Expected: after the resume, the leader runs the routes of the policy, and a 
> node that is not the leader does not.
> Suggested fix: do not start the routes while the CamelContext is suspending 
> or suspended; on {{CamelContextResumedEvent}} apply the leadership again 
> (start the stopped routes on the leader, stop the started ones elsewhere), on 
> the policy thread. Note that the resumed event comes while the CamelContext 
> status is still starting, so the start must not be deferred to the started 
> event, which does not come again.
> Found with Specula (TLA+ model checked against traces of the real code) and 
> code review, and confirmed with tests on the real classes.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to