Since the update to openfire 4.7.4 and Monitoring plugin 2.4.0, users are kicked out of rooms.
The log message says:
TaskEngine-pool-392]: org.jivesoftware.openfire.muc.spi.MultiUserChatServiceImpl - Skip removing as a cluster-wide mutex for the room could not immediately be obtained: Occupant ‘xxx’ of room ‘xxxxxx’ (real JID ‘firstname.lastname@example.org/39ertrzxd0’, last active 2022-11-22T08:06:59.601089Z), should have been removed, because: User seems to be unreachable (didn’t respond to a ping request).
This never happened before the update. And all checks on network (because of the ‘didn’t respond to a ping request’) showed no problems.
Any idea what this is?
Did you get any feedback?
I also have the same problem
Does this problem also occur without the Monitoring plugin being installed?
Yes, the problem stays even after Monitoring plugin was removed.
Could this be a cause:
That is possible, yes. What was the old version of Openfire that you upgraded from?
I updated from 4.6.6 to 4.7.4.
With 4.6.6 no problem occured.
Can you try if changing these settings affects the behavior? I’m not sure if you need to restart Openfire after changing the settings (it’s safest to do so).
These settings can be used to enable/disable a feature that detects if a user is ‘idle’, and therefore remove from the room. You can find that setting in the Admin Console, under “Group Chat” > “Group Chat Settings” > (click on a service) > “Other Settings”
A few days after disabling the idle check, it seems the problem is gone.
Also, it seems the problem depends on the used client. Gajim and Pidgin have less (or none) ‘kicked’.
But Thunderbird has it very often.
This might suggest a bug in Thunderbird. It should always respond to the keepalives that Openfire sends (even if it’s with an error), but it appears that it does not. What version of Thunderbird are you using?
I asked the Thunderbird users and they used version 102.6.0 and 102.4.2.
But the problem never occured with openfire 4.6.6.
Openfire was modified in the not-so-distant past to add better detection of occupants of a room whose clients had already disconnected. That’s likely contributing to this.
I think that I’ve reproduced the problem. Is this the type of error that you see in Thunderbird?
(note that I modified configuration to make the issue occur after 1 minute of inactivity. By default, it would take 60 minutes of inactivity to trigger)
Yes, that sure is it.
A fix got merged in the Thunderbird client. I expect it to become available in release 110 of Thunderbird.
Thanks @guus for the contribution to have a better XMPP support in Mozilla Thunderbird!