We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY

Ran a leader election, it was successful. On the callback i am fetching getLeadership which is timing out.io.atomix.primitive.PrimitiveException$Timeout: null
at io.atomix.core.election.impl.BlockingLeaderElector.complete(BlockingLeaderElector.java:120) ~[atomix-2.1.0-beta1.jar:?]
at io.atomix.core.election.impl.BlockingLeaderElector.getLeadership(BlockingLeaderElector.java:75) ~[atomix-2.1.0-beta1.jar:?]

@johnou unfortunately we’re probably not upgrading for another month or so. The reason is just because we’re working on upgrades. But I don’t think much more is going to be done on the 2.0 Raft implementation any more so we shouldn’t have much to cherry pick. We’re pretty sure we’ve worked out all the bugs. Everything else we can probably fix in 2.1 and backport, especially with the test framework working in 2.1

I’m all for doing another beta release

I’m also going to move the CLI and test framework into their own repos

@vvarma this might be a deadlock. The low level Raft clients have some logic for handling blocking inside event threads, but that may be getting obscured by the various higher level adapters/decorators.

Raft events and responses are received on the same thread to ensure consistent ordering. The Raft clients check whether futures are blocked before completing them on the response/event thread and use a thread pool instead for blocked futures. But higher level wrappers can create their own futures that obscure blocking of the lower level futures.

There may be a better way to do blocked thread checking and avoid deadlocks inside response/event threads