I found that MUC occupants are removed prematurely in the following situation with OpenFire 3.7.0:
Join a MUC room using BOSH. This will result in a presence with a full JID such as moderator@example.com/61ef51b5
Kill the BOSH connection hard (without leaving the MUC room)
Join the same MUC room with the same nickname, again using BOSH. This will result in a second presence with a different JID such as moderator@example.com/e4a9752b
After 60 seconds, the first HTTP connection will time out, causing the first JID (moderator@example.com/61ef51b5) to leave the MUC room
Even though the second JID (moderator@example.com/e4a9752b) is still in the room, the user “moderator” has been removed from the occupants list.
Am I correct in assuming that this is a bug? If so, I believe it can be fixed with the attached patch.
Would you agree that the behaviour is at least surprising? The second JID is still in the room, for example it still receives messages from other participants, but it’s not listed as an occupant.
The patch is against trunk but it applies cleanly against 3.7.0. I haven’t tested with 3.7.1 yet, I’ll do that today, but I’d be quite surprised if there’s a difference.
It sounds like a bug, but i don’t use BOSH, so i don’t know if this patch won’t cause issues in some other place. What does you patch do exactly to fix this issue?
LocalMUCRoom maintains a list of occupants by bare JID in “occupantsByBareJID”. Each entry maps to a list of full JID. When a full JID leaves the room, it is removed from that list, but the map entry is only removed when the list is empty. So if two full JIDs with the same bare JID are in the room and one of them leaves, there is still an entry for the bare JID in “occupantsByBareJID”.
However, the nickname is removed from the “occupants” map every time a full JID for that nickname leaves the room. The patch changes this so that the entry is removed from “occupants” only once the corresponding entry in “occupantsByBareJID” is removed. Does this make sense?
Regarding BOSH, I haven’t tried with other protocols but I’d expect that the same issue can be reproduced by joining a room twice with the same nickname and different full JIDs (different session IDs), then having one of the two leave the room, regardless of protocol.
By the way, in the meantime I’ve tried with 3.7.1 and I can confirm that the same issue is present there. However I was wrong, the patch against trunk doesn’t apply cleanly, I’ll add another patch for 3.7.1.