These are chat archives for atomix/atomix

25th
Apr 2017
terrytan
@txm119161336_twitter
Apr 25 2017 03:00
Yes ,i have read that doc ,But when does the server get promoted ?
terrytan
@txm119161336_twitter
Apr 25 2017 03:07
"Once the server is caught up, it will become a full voting member so will continue to receive AppendEntries RPCs from the leader at normal intervals anyways. Thus, it makes sense for the leader to include new servers in AppendEntries RPCs." This means once the passive catches up , the follower check its returning index ,if i matches the recent index, then it gets promoted ? I have seen interface demote and promote in copycat servermember class ,but it is never invoked by anyothers
Johno Crawford
@johnou
Apr 25 2017 09:37
@jhalterman just incase you missed it, I updated the code in the gist to the o(1) solution, not as tricky as I had originally thought :)
Jordan Halterman
@kuujo
Apr 25 2017 09:50
@jhalterman never pays attention to this thing
@jhalterman!
@jhalterman!
@jhalterman!
@jhalterman!
@jhalterman!
:-P
Jordan Halterman
@kuujo
Apr 25 2017 09:59

@txm119161336_twitter nice to see you!

That API is never called in Copycat because it's just a user API in the Member interface, and it may stay that way.

That documentation may be out of date. Copycat used to catch up servers before promoting them during a reconfiguration, but when passive/reserve nodes were added that was removed and just hasn't been added back in yet. This is actually on my todo list, but it's pretty low priority since it's not personally affecting at the moment :-P

It will be added back in when I finally get to working on fault tolerance for partitions in our cluster. I don't expect that to happen too soon. Likely ahead of it is rewriting the log and serialization in Copycat (which is most of the way done) and the migrating cluster management, messaging, failure detection, partitions, transactions, eventual consistency, and lots of other things into Atomix. But TBH promoting servers when they're caught up is trivial and there's no reason it can't be squeezed in and hacked out in a day.

I'm not sure whether we'll just expose a listener in Member that indicates when a server is caught up. That's probably impractical since it has to be replicated. Only the leader can determine whether something is caught up. So we probably just need to add a PROMOTABLE state instead.

Dave
@qorpus
Apr 25 2017 18:59
Hi there, I actually have an odd problem, I am getting an atomix lock, inside that lock I am trying to look up some values in a named map, but it would appear that when trying to access the map while inside a locks completeable future, im blocked
example atomix.getLock("bob").thenAccept( lock -> { sout(atomix.getMap("john").join().get("key") });
the call to atomix.getMap().join never actually returns
Dave
@qorpus
Apr 25 2017 19:07
has me a little stumped, thats for sure
Dave
@qorpus
Apr 25 2017 19:45
atomix.getLock("testlock").thenAccept(distributedLock -> { distributedLock.lock().thenAccept(bob->{ atomix.getMap("hihihi").join(); }); });
Dave
@qorpus
Apr 25 2017 20:08
actually so
if I break them all out
same thing
Distributed lock = atomix.getLock("testlock").join(); Long lockVal = lock.tryLock(duration).join(); atomix.getMap("testtesttest"); sout("i never get here"); lock.unlock();