camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luca Burgazzoli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-11457) camel-atomix - No new leader when all nodes are killed forcefully
Date Tue, 27 Jun 2017 05:41:00 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064304#comment-16064304
] 

Luca Burgazzoli commented on CAMEL-11457:
-----------------------------------------

Yeah, looks like an issue with the persistent member which can be reproduced outside camel.
Will add an option to use ephemeral members so we have a workaround till I found a way to
properly recover from this.


> 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
>
> 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)

Mime
View raw message