Merged into master.

I've got a potential fix for detecting dropped S2S connections (and other MUC delivery-related errors). I believe this will address some of the reported MUC user synchronization issues reported here. Updated PR pending review.

I see this too, but am unsure if it is cluster related or just fun that exists with s2s and MUC in general. Having the remote server 'go away' without notification to the local server that the user is now gone away to, leaves things in a difficult state.

I would test this in a federated scenario i.e. when a user from a remote server connects to a clustered openfire instance. I have strange sporadic problems with MUC open_chat@conference.igniterealtime.com from an account on a different server.

I have not been able to reproduce this issue. Here is what I have tested:

• Two OF servers in cluster (via Hazelcast)

• Two chat users (via Spark and Pidgin) each connected to a different OF cluster member

• Multiple join/leave/chat interactions in a MUC room between users

• Tested with various MUC room configurations (permissions, options, etc.)

I have verified the following:

• Presence messages (joined/left room) are being delivered to both clients

• Chat messages are delivered to the room and displayed on both clients

• Room occupant count is kept up to date on all cluster members and clients

I will drop this issue back into the pool for now until we can get more detail with some specific steps to reproduce the issue.