These are chat archives for atomix/atomix

9th
Jan 2017
Thiago Santos
@thiagoss
Jan 09 2017 13:53
@kuujo I think I understood why the fix from last week was not enough. In this case, the commit index in the configure is greater than the one of the instance that did the leader->follower transition. So it doesn't prevent it from committing the wrong entry.
Thiago Santos
@thiagoss
Jan 09 2017 14:49
I don't get this. When it transitions to follower, it should truncateUncommittedEntries, which would remove the requests that were just appended. Why doesn't that help with the issue?
hazemkmammu
@hazemkmammu
Jan 09 2017 16:15
@thiagoss Sorry to make your questions cluttered by commenting in between. I don't see any other way. @kuujo I am trying to send a direct message to a group member. If I do a
Member member = group.member("foo");
Thiago Santos
@thiagoss
Jan 09 2017 16:17
No worries :)
hazemkmammu
@hazemkmammu
Jan 09 2017 16:19
I accidentally hit enter by making my last message incomplete :) If I do a
Member member = group.member("foo");, will I get a null when the member node 'foo' is down? If yes, is there a way around it? I would like to send direct messages to a persistent member even if it is down (assuming it has joined the group once)
hazemkmammu
@hazemkmammu
Jan 09 2017 16:53
I just verified that group.member("foo") returns null when foo is down. I was expecting to be non null and any messages directed to foo to be queued until it rejoins.
hazemkmammu
@hazemkmammu
Jan 09 2017 17:05
One way to solve this problem would be to use broadcast and specify the recipient member id in the message. This way, the recipient node can check the member id and see if it's directed towards it. I hope there's a better solution :)