> It's a bit tricky : > > the session can be connected, but the sessionCreated event might not be > called yet. As we need to get the 'lock' object which is injected into the > session to run the test, we have to wait for the sessionCreated to be > executed (because this is the place where this lock is added to the > session). > > Now, the session.isConnected() method is a bit crippled. It's set to false > when the session is closed (and it can take some time, as many listeners may > be called and we will wait for their completion), but there is no place > where the session is set to connected. It's simply considered as connected > unless it's closed. o there are some race condition where the session will > be considered as connected, even if all the initialization is not done > (typically, if we are waiting for this 'lock' to be stored into the > session), which may make the test fail. > > Sounds crazy, but trust me, this part of the code is more insane than I am > :) > > PS : I'm pretty sure that a better session state mechanism could be > implemented. It sound totally crazy that a session is considered to be > "connected" simply because it's not closed. At least two new states should > be added ( "Initializing" and "connected").
Fair enough. tcp/ip has an easy enough state diagram to google for. udp being connectionless doesn't seem to have such a diagram.
