powered by Jive Software

MUC occupants are removed prematurely

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.

Added patch against 3.7.1.
openfire_muc_occupants_removed_prematurely.patch.zip (618 Bytes)
openfire_muc_occupants_removed_prematurely_3_7_1.patch.zip (638 Bytes)

Can’t say whether it is bug or not. Did you create this patch against current 3.7.2 trunk? Have you tested this with 3.7.1?

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.

Hmm… actually, I’m not 100% sure if the patch works when users change nicknames.

OpenFire doesn’t have a test suite, does it?

What do you mean by test suite?

I will forward this thread to another user, who is using BOSH and maybe he will have better understanding about this patch.

By test suite I mean a set of unit tests or functional tests to which I could add a test for this specific problem.

I’m not a developer myself, so can’t say.

Daryl replied that Guus (on of the devs) probably will look into this next week.

Great, thanks for your help so far!

There are some tests @ http://fisheye.igniterealtime.org/browse/openfire/trunk/src/test

But not so many and IIRC none of them tests the MUC behavior.

While reading your bug report, OF-103 came to my mind. I think that this feature and your bug could be fixed together.

Good to know, thanks. Yes, OF-103 looks related.