These are chat archives for atomix/atomix

15th
Jun 2016
Tom
@taobaorun
Jun 15 2016 02:35
hi,statemachine holds all sessions,how the statemachine publish event to specific client?
Jordan Halterman
@kuujo
Jun 15 2016 02:39
Normally, you associate a command with a session. Each Commit has a reference to the Session that submitted that command via commit.session(). So, e.g., in Atomix a DistributedLock submits a Lock command, and the state machine sends an event to commit.session() to notify that client when it receives the lock.
Then, usually the state machine implements the close(ServerSession) method to detect when a client unregistered its session or the session is expired. For example, the lock state machine releases any locks held by the closed session.
Basically, if you want a specific client's session submit a command from that client that behaves as a registration and get the reference to that specific client's session via commit.session() in the state machine
Tom
@taobaorun
Jun 15 2016 02:48
thanks,i want to notify the related clients which subscribed the same service
Jordan Halterman
@kuujo
Jun 15 2016 03:20
Yep that's the way to do it. Make a Subscribe command, store sessions related to a service, then publish to all sessions associated with a service.
Tom
@taobaorun
Jun 15 2016 03:25
public class MapStateMachine extends ResourceStateMachine {
      private final Map<Object, Object> map = new HashMap<>();
      private final Set<ServerSession> listeners = new HashSet<>();

      public void listen(Commit<ListenCommand> commit) {
        listeners.add(commit.session());
      }

      public void put(Commit<PutCommand> commit) {
        map.put(commit.operation().key(), commit.operation().value());
        for (ServerSession listener : listeners) {
          listener.publish(commit.operation().key(), commit.operation().value());
        }
      }

      public void close(ServerSession session) {
        listeners.remove(session);
      }
}
just like this
Jordan Halterman
@kuujo
Jun 15 2016 04:03
Yep perfect
Tom
@taobaorun
Jun 15 2016 05:16
@kuujo thanks
Tom
@taobaorun
Jun 15 2016 07:57
@kuujo when only one client connected the cluster and then kill the client.the statemachine didn't trigger the session listener.
Jordan Halterman
@kuujo
Jun 15 2016 07:58
did you change the session timeout or anything?
Tom
@taobaorun
Jun 15 2016 07:58
no
if another client connected,the last client session listener triggered.
Jordan Halterman
@kuujo
Jun 15 2016 07:59
hmm… yeah I think I know the problem
I remember this… the problem is, the logical time that’s used to expire sessions only progresses when clients are connected. When a client sends a keep-alive, the logical clock in the state machine increases, and that’s when sessions can be expired. If no clients are connected then sessions won’t be expired. I’m not sure it matters too much. The session will still be expired prior to the next session being registered IIRC, and for that reason whether a session expires at the expiration time or when another client connects doesn’t effect determinism. The problem is, progressing time in the state machine requires a write to the log, and it would incur unnecessary cost to do so just to progress the clock when nothing else is going on.
progressing the clock requires a write to the log to ensure all state machines progress at the same rate
that would mean the leader would have to write to the log periodically, and that’s probably not a good idea
Jordan Halterman
@kuujo
Jun 15 2016 08:16
@madjam I see your PRs. I’ve been caught up in work stuff but will check them out in the morning
Tom
@taobaorun
Jun 15 2016 08:21
@kuujo i see,thanks
Tom
@taobaorun
Jun 15 2016 08:27
The session will still be expired prior to the next session being registered
[15/06/16 04:14:26:338] RegistrationStateMachine 117 - register session:4668 //new session
[15/06/16 04:14:26:382] RegistrationStateMachine 127 - expire session:4633// last session
[15/06/16 04:14:26:382] RegistrationStateMachine 132 - close session:4633
Jordan Halterman
@kuujo
Jun 15 2016 08:27
that’s a bug then
althought it doesn’t really matter… what matters is determinism, but that seems like it could cause unexpected issues so might as well fix it
added an issue for it and I’ll fix it tomorrow
should push a new release at the end of the week once we get all the pull requests worked out
Tom
@taobaorun
Jun 15 2016 08:30
ok
Tom
@taobaorun
Jun 15 2016 08:42
i found these log, when i kill one server,and then start it.if there is something wrong?
Jordan Halterman
@kuujo
Jun 15 2016 08:45
?
might have missed a message
Tom
@taobaorun
Jun 15 2016 08:50
RegistrationStateMachin- register session:6
[15/06/16 04:40:15:273] RegistrationStateMachine 117 - register session:16
[15/06/16 04:40:15:284] RegistrationStateMachine 127 - expire session:6
[15/06/16 04:40:15:285] RegistrationStateMachine 132 - close session:6
[15/06/16 04:40:15:304] RegistrationStateMachine 117 - register session:25
[15/06/16 04:40:15:305] RegistrationStateMachine 127 - expire session:16
[15/06/16 04:40:15:305] RegistrationStateMachine 132 - close session:16
[15/06/16 04:40:15:309] RegistrationStateMachine 117 - register session:54
[15/06/16 04:40:15:311] RegistrationStateMachine 127 - expire session:25
[15/06/16 04:40:15:311] RegistrationStateMachine 132 - close session:25
[15/06/16 04:40:15:312] RegistrationStateMachine 117 - register session:75
[15/06/16 04:40:15:313] RegistrationStateMachine 127 - expire session:54
[15/06/16 04:40:15:313] RegistrationStateMachine 132 - close session:54
[15/06/16 04:40:15:313] RegistrationStateMachine 117 - register session:85
[15/06/16 04:40:15:313] RegistrationStateMachine 127 - expire session:75
[15/06/16 04:40:15:313] RegistrationStateMachine 132 - close session:75
Jordan Halterman
@kuujo
Jun 15 2016 08:51
when does this happen?
Tom
@taobaorun
Jun 15 2016 08:51
i just closed one server node.and then start it up
Jordan Halterman
@kuujo
Jun 15 2016 08:52
yeah… it’s likely replaying the log
which it will do at startup to rebuild the state machine state
part of the state machine’s state includes sessions that were registered
eventually those will be compacted from the log once they’re no longer needed, but until then they’ll be replayed along with everything else at startup
the end result being that the server recovers to the state in which it was when it died, or more precisely the same state as other servers
In your case, your state machine is just adding and then removing them from the Set
Tom
@taobaorun
Jun 15 2016 08:58
public class RegistrationStateMachine extends StateMachine implements SessionListener {

    private static final Logger logger = LoggerFactory.getLogger(RegistrationStateMachine.class);

    private Map<String,List<Commit<RegisterCommand>>> rcMap = new HashMap<>();

    private Map<String,List<Commit<SubscribeCommand>>> subscribeMap = new HashMap<>();

    @Override
    public void init(StateMachineExecutor executor) {
        executor.context().sessions().addListener(this);
        super.init(executor);
    }
 executor.context().sessions().addListener(this);
Jordan Halterman
@kuujo
Jun 15 2016 08:59
IIRC you should be able to omit that line. If the StateMachine implements SessionListener it will automatically be added in Copycat
It’s already added without overriding init at all
Tom
@taobaorun
Jun 15 2016 09:02
i see,thanks.:smile:
Jordan Halterman
@kuujo
Jun 15 2016 09:09
np I’m gonna be heading to bed soon but I’ll be back around in the morning (in California)
Tom
@taobaorun
Jun 15 2016 09:10
:full_moon:
Madan Jampani
@madjam
Jun 15 2016 17:09
@kuujo thanks. I was wondering if we can get a rc for atomix created with all the current fixes. We are working on a getting a rc for ONOS today and I wanted to use the latest atomix as part of that.
Jordan Halterman
@kuujo
Jun 15 2016 17:09
Definitely
Will push it after we merge everything
Madan Jampani
@madjam
Jun 15 2016 17:10
Awesome! thanks!
Jordan Halterman
@kuujo
Jun 15 2016 22:55
on its way
Madan Jampani
@madjam
Jun 15 2016 23:55
great! thanks.