I was wondering if the reconnect mechanism was defined enough for to to give us some info on it. Some of the questions I have about the reconnect process include:
Obviously this all applies to the full multi-stack...
1) Does the AppListener's loggedIn() method get called again when a user reconnects? I am guessing not!
Correct. Also you do not get a disconnected message until the reconnect window has passed without a reconnect.
2) I am assuming that the original ClientSessionListener's disconnect method never gets called if they reconnect within the alloted time even if they reconnect to a different node in the cluster?
Yup see above
3) Does the user's ClientSessionId change when they reconnect?
I don't *believe* so. I need to double check that with the comm team but I bleieve to all external view its as if the client never left.
The only reason why we have a "reconnecting/reconnected" callback in the client API is because there are things clients may want to stop doing during a reconnecting, such as pumping a flood of packets, and they may want to alert the user as to why the pause. (eg "Lost Connection To Server" type messages)
4) Does the user's ClientSession get reused or recreated?
ClientSession remains valid
5) Should we be referencing ClientSession with ManagedReference or can a java reference do the job and how does that work as it relates to a user reconnecting to a different node upon a server failure?
Java reference. (ClientSession is not defined as being a ManagedObject.)
6) Since we bind a user to a channel using the ClientSession and if the user reconnected to another node in the cluster due to server failure obviously the object couldn't be the same as it relates to session == session.. Does that matter?
No. Its the contents of the ClientSession object that really matter and those are duplicated.
Routing between nodes is totally invisible to you.
[/quote]
