These are chat archives for atomix/atomix

23rd
Feb 2018
vvarma
@vvarma
Feb 23 2018 08:30
thanks @johnou @kuujo got it working with 2.1.0-beta1!
Johno Crawford
@johnou
Feb 23 2018 08:41
@kuujo might be worth going through the remaining prs and creating beta2?
vvarma
@vvarma
Feb 23 2018 15:33
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:?]
Jordan Halterman
@kuujo
Feb 23 2018 21:12
@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.
Jordan Halterman
@kuujo
Feb 23 2018 21:17
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