[
https://issues.apache.org/jira/browse/CAMEL-25089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-25089:
-----------------------------------
Assignee: Claus Ibsen
> camel-cluster - Clustered route policy and file lock cluster: fix bugs found
> in a deep review
> ---------------------------------------------------------------------------------------------
>
> Key: CAMEL-25089
> URL: https://issues.apache.org/jira/browse/CAMEL-25089
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-file
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Minor
>
> A review of the clustering support (camel-cluster, the cluster service
> support in camel-support, and the file lock cluster service in camel-file)
> found these bugs:
> # *FileLockClusterView* does not tell its listeners that the leadership is
> lost when the view is stopped while it is the leader (the {{stopView}} JMX
> operation, stopping the cluster service, or stopping the clustered route
> controller). The clustered routes and the {{master}} consumers keep running
> while the file lock is released, so another member takes the leadership and
> both members run the routes.
> # *ManagedClusterService* (JMX) {{getNamespaces}}, {{startView}},
> {{stopView}} and {{isLeader}} look up a cluster service with the default
> selector instead of using the service of the mbean, so with more than one
> cluster service they do nothing or answer wrongly.
> # *ClusteredRouteController.setClusterServiceSelector* checks the cluster
> service instead of the selector argument, so it always fails when no cluster
> service is set. The route policies it creates also ignore the selector, as
> the cluster service is not looked up yet when the policies are created.
> # *ClusteredRoutePolicy*: the {{initialDelay}} is skipped when the leadership
> is taken after the CamelContext has started (which is common with the file
> lock cluster service), and the routes are started right away.
> # *ClusteredRoutePolicy*: a removed route is kept in the started/stopped
> routes of a shared policy, so the policy stops (or starts) another route that
> is added later with the same route id when the leadership changes.
> # *AbstractCamelClusterService.doStart* starts all its views, also the views
> that are no longer used (their routes have been removed), so after a
> stop/start of the cluster service a file lock member takes a lock of a
> namespace it does not use.
> # *FileLockClusterView* fails with ArithmeticException (/ by zero) when the
> {{acquireLockInterval}} is less than 1 millisecond (such as 500
> MICROSECONDS). It is now rejected with a clear error.
> # The cluster services found by type are returned in no particular order, so
> the {{first}} (and type/attribute) selectors do not pick the same service
> every time.
> Not changed:
> * The route policy created per route by ClusteredRoutePolicyFactory /
> ClusteredRouteController is not cleaned up (its event notifier, thread pool
> and service) when the route is removed, only when the CamelContext is shut
> down. A shared policy can be used again by a route added later, so this needs
> its own change.
> * After a stop/start of the CamelContext the clustered routes are not started
> again (the policy thread pool is shut down on stop).
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
