shashank created CAMEL-26801:
--------------------------------
Summary: camel-zookeeper - a ZooKeeper cluster service stopped and
started again never takes the leadership again
Key: CAMEL-26801
URL: https://issues.apache.org/jira/browse/CAMEL-26801
Project: Camel
Issue Type: Bug
Components: camel-zookeeper
Reporter: shashank
Assignee: shashank
{{ZooKeeperClusterView}} keeps the Curator client that
{{ZooKeeperClusterService}} gave it when the view was created. When the service
is stopped and started again (for example from JMX), it closes its managed
Curator client and creates a new one, and starts its views again (the views in
use are kept by the service). A view then creates its {{LeaderSelector}} on the
closed client:
* the node no longer takes part in the leader election: it never becomes the
leader, also when all the other nodes go away;
* the routes that use the view (clustered route policy, {{master}} component)
never run on this node again. A restart of the CamelContext stops and starts
the same service, which keeps its views, so it hits the same problem; only a
restart of the application recovers.
This is the ZooKeeper counterpart of CAMEL-25061 (file lock cluster service
restart).
Expected: a view started again after a restart of its service takes part in the
election with the current client of the service.
Suggested fix: the view gets the client from the service when it starts,
instead of keeping the one it was created with.
Found with Specula (TLA+ model checked against traces of the real code) and
confirmed with a test on the real classes (ZooKeeper server in the test JVM).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
