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.
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 firstname.lastname@example.org from an account on a different server.
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'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.
Merged into master.