You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Luca Burgazzoli (JIRA)" <ji...@apache.org> on 2017/09/12 07:00:03 UTC

[jira] [Closed] (CAMEL-11457) camel-atomix - No new leader when all nodes are killed forcefully

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

Luca Burgazzoli closed CAMEL-11457.
-----------------------------------
    Resolution: Won't Fix

Won't be fixed upstream, should be fixed with Atomix 2.0

> 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
>            Assignee: Luca Burgazzoli
>            Priority: Minor
>             Fix For: 2.20.0
>
>
> 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)