Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

OccupantManager doesn't remove all items when clustering

Description

When Openfire is running a cluster, after a while of running, cache cluster inconsistencies are reported in MUCs.

e.g. The list of occupants by node has 85 elements, and does not equal the list of occupants seen in rooms, which has 52 elements

(as seen on https://xmpp.igniterealtime.org:9091/system-clustering-data-consistency-check.jsp)

Through a diff of the two displayed lists (the list of 85 contains all 52 plus additions) and contacting users who have the discrepancies (e.g. 1 resource in the short list, 2 resources in the long list) we’ve been able to ascertain that the short list, derived from the Cache, is the correct list, and the OccupantManager’s in-memory list is not removing all occupants as they leave.

Environment

None

relates to

Activity

Show:

Daryl Herzmann February 22, 2024 at 3:40 AM

About to test this on Ignite, so will leave the issue open for now.

Guus der Kinderen February 19, 2024 at 8:18 PM

I’m not sure why we’re keeping track of more-than-one cluster node for an Occupant. Do we do this only to accomodate federated users (that are not physically connected to exactly one cluster node)?

If that’s the case, then I wonder if it’s an improvement to somehow make sure that these occupants are never associated with any particular cluster node (in effect, associate them with ‘all’ nodes). My rationale is that even if a cluster node goes down (which would make a local user disconnect), the remote user is still reachable (as any cluster node can re-establish federation).

Guus der Kinderen February 19, 2024 at 8:06 PM

This might relate to users on federated domains that join a MUC on the local domain. These users can somehow be associated to multiple cluster nodes. When the occupant is removed by one node, it remains a registered ‘occupant’ of the other node.

Fixed

Details

Assignee

Reporter

Fix versions

Priority

Created February 13, 2024 at 7:37 PM
Updated March 2, 2024 at 1:04 PM
Resolved March 2, 2024 at 1:04 PM