These are chat archives for atomix/atomix

5th
Jan 2016
Jordan Halterman
@kuujo
Jan 05 2016 03:17
Thanks!
I definitely think the transport(s) should be improved upon. I was going to stick SSL in there originally but it was too much of a PITA to worry about then. But definitely would be nice to have
Richard Pijnenburg
@electrical
Jan 05 2016 10:32
Hiya @kuujo
Jordan Halterman
@kuujo
Jan 05 2016 10:32
hey
I’m about to merge the last major API changes and go to bed
tired
Richard Pijnenburg
@electrical
Jan 05 2016 10:33
hehe okay :-)
with that latest one, does it mean its part of a group at all times ?
ah. and i see you support multiple group members now. i was looking for tht :D
Jordan Halterman
@kuujo
Jan 05 2016 10:35
but now the atomix Maven artifact has an API like so:
Atomix atomix = AtomixClient.builder(…)…build();
DistributedMembershipGroup group = atomix.getMembershipGroup(“foo”);
LocalGroupMember member = group.join().get();
member.onElection(term -> {
  System.out.println(“Elected leader!”);
});
so, election is done for membership groups and you can either pay attention to it or not
Richard Pijnenburg
@electrical
Jan 05 2016 10:36
Ahh very nice
Jordan Halterman
@kuujo
Jan 05 2016 10:36
long term = group.term();
GroupMember leader = group.leader();
group.onElection(member -> …)
etc
now that configurations are possible (though none have been implemented) we can start adding configuration stuff to configure e.g. the fairness of elections
Richard Pijnenburg
@electrical
Jan 05 2016 10:38
I was looking for having a node part of multiple groups so that if a node joins a group or multiple groups the leader logic can then push specific configs to that node based on those groups
Jordan Halterman
@kuujo
Jan 05 2016 10:40
hmm
Richard Pijnenburg
@electrical
Jan 05 2016 10:44
or i need to add some arbirary meta data to the host it self
Also i was thinking of having a persistent UUID for each instance might be handy
Jordan Halterman
@kuujo
Jan 05 2016 10:45
Yeah I was just thinking that actually
Richard Pijnenburg
@electrical
Jan 05 2016 10:45
Not sure how you would save it in the client though since it doesn't use any storage.
Jordan Halterman
@kuujo
Jan 05 2016 10:45
Yeah that's the problem
Richard Pijnenburg
@electrical
Jan 05 2016 10:46
But i think its the same case for other things like Elasticsearch anyway.
Jordan Halterman
@kuujo
Jan 05 2016 10:50
The only way to do this really is to have the leader coordinate the cluster. The leader says "process A start on node B with UUID foo" and the process starts and recovers whatever state it needs using that UUID. But to that end, maybe DistributedMebershipGroup could allow a user provided UUID. Membership groups do have a way to store metadata associated to a member, and that could help recover it: member.set("foo", "bar") and member.get("foo")
Richard Pijnenburg
@electrical
Jan 05 2016 10:50
Hmm yeah indeed.
Jordan Halterman
@kuujo
Jan 05 2016 10:50
If the user provides a UUID for the member them that state is recovered when it rejoins
And is only deleted if the member explicitly leave()s
K gotta go to sleep sowwy :-P
Richard Pijnenburg
@electrical
Jan 05 2016 10:51
hehe np bud. catch you in your morning.
Jordan Halterman
@kuujo
Jan 05 2016 10:51
Gonna test and merge it tomorrow
Richard Pijnenburg
@electrical
Jan 05 2016 10:52
okay cool.
Jordan Halterman
@kuujo
Jan 05 2016 19:17
Probably won't be around too much today. I have a day full of meetings. Everyone's always motivated to change when the big number on the calendar changes.
Richard Pijnenburg
@electrical
Jan 05 2016 20:45
Hah no worries.
Jordan Halterman
@kuujo
Jan 05 2016 22:56
I hate meetings
Richard Pijnenburg
@electrical
Jan 05 2016 23:01
Haha I know that fe
Feeling
I avoid them as much as I can