These are chat archives for atomix/atomix

May 2016
May 30 2016 12:39
i have started copycat 3 servers and all of them register putCommand and getQuery as in the example ,let call it app1 app2 and app3. first i have started app1 and app2.app2 selected as leader. then i have started client to put ('foo','bar') command . i can see app1 and app2 both received that. after that i started app3. but it didn't received the command from the leader. any idea?
May 30 2016 13:23
ahh got it. reason is commit immediately close after the map insertion , which cause immediate compaction , correct me if i'm wrong.
Roman Pearah
May 30 2016 20:14
@kuujo I'm trying to revisit the whole Atomix-on-Docker issue. If you recall, the problem is that the replica advertises the same address:port it binds to, so you cannot connect a client from the outside without resorting to --net=host. I think that if it were possible to configure a different advertised address and/or port for connections, that would solve the problem.
@kuujo Following that logic, I was able to get it to work without --net=host by making use of dnsdock. It required some setup on my local machine, but it seems to work beautifully.
I just made sure to set up the replica with the host and port for the DNS name a set via environment variables in my docker compose file.
Roman Pearah
May 30 2016 21:55
This may have been discussed before, but what, if anything, is the method for notifying a client that a resource has changed since the last known value, i.e. along the lines of ZooKeeper's znode watches?
Jordan Halterman
May 30 2016 22:31
This just needs to be added to resources, and it’s easy to do. Essentially the same mechanism that ZooKeeper uses for watches is used in Copycat for state machine events, but Copycat’s events have a few more guarantees. We just need to add change events to the base state machine, which I think would be really easy to do. The question is, should we add generic change events to all state machines, or let individual state machines implement their own change events? i.e. is it enough to say something changed, or should we allow individual state machines to say what changed (e.g. the key with old and new value in a map)

basically, to add them all we have to do is publish an event from the appropriate state machine:

public class SomeStateMachine extends ResourceStateMachine {
  public void someCommand(Commit<SomeCommand> commit) {
    listeners.forEach(l -> l.session().publish(“change”, “something changed”));

Then on the client side in the Resource class listen for that event

public CompletableFuture<T> open() { -> {
    client.onEvent(“change”, this::onChange);
would definitely be nice to add more events… I know they’re needed