[
https://issues.apache.org/jira/browse/CAMEL-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064278#comment-16064278
]
Luca Burgazzoli commented on CAMEL-11457:
-----------------------------------------
I need to digg into this a little bit more but the client nodes are "persistent
nodes" which requires them to explicit leave the cluster so halt may mess
things up.
> camel-atomix - No new leader when all nodes are killed forcefully
> -----------------------------------------------------------------
>
> Key: CAMEL-11457
> URL: https://issues.apache.org/jira/browse/CAMEL-11457
> Project: Camel
> Issue Type: Bug
> Components: camel-atomix
> Reporter: Nicola Ferraro
> Priority: Minor
>
> I'm testing the leader service with the following scenario.
> Client mode with an external bootstrap service on Openshift. Using a
> spring-boot application.
> The service configuration is:
> {code}
> AtomixClusterClientService service = new AtomixClusterClientService();
> service.setId(InetAddress.getLocalHost().getHostName());
> service.setNodes(Collections.singletonList(new Address("atomix-boot-node",
> 8700)));
> {code}
> Steps:
> - I start 3 pods of the application, one is the leader.
> - Once started, I kill forcefully all three pods (calling
> "Runtime.getRuntime().halt(1)" from the JVM code) one after the other at
> short distance (few seconds)
> When all three pods become available again, the "leadershipChanged" callback
> is not called in any of the pods (waited > 1 hour). If I restart one pod
> after some time, that one become the leader. The other two pods receive the
> notification that there's a new leader.
> It seems that a timeout occurs, so that a new leader can be determined upon
> restart, but nobody participate in the election if pods are started before
> the timeout.
> [~lb] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
