Openfire (master)

• 

  daryl herzmann <akrherz@iastate.edu> 22 Feb 2024 5d62ef9df1fcda29a95ca445aa85643c9d557df0

  Merge pull request #2424 from guusdk/OF-2799_MUC-Occupant-management-cluster
  OF-2799: MUC occupant management for federated users in a cluster
• 

  Guus der Kinderen 21 Feb 2024 df87d2ba10160353b14d0b5ba31804bea2ce14fb m

  OF-2799: Fix Consistency Checks for updates in previous commit (compare collections based on content only, not on order).

  • xmppserver/src/main/java/org/jivesoftware/util/cache/ConsistencyChecks.java (version df87d2ba10160353b14d0b5ba31804bea2ce14fb)
• 

  Guus der Kinderen 21 Feb 2024 46232c2998e974eab7b971f52b5674f23cb6a5a2 m

  Applied IDE-suggested improvements to ConsitencyChecks (no functional changes)

  • xmppserver/src/main/java/org/jivesoftware/util/cache/ConsistencyChecks.java (version 46232c2998e974eab7b971f52b5674f23cb6a5a2)
• 

  Guus der Kinderen 21 Feb 2024 bdb88c652208c895164f4a7595b6def84740a4dd m

  OF-2799: Fix Consistency Checks for updates in previous commit.

  • xmppserver/src/main/java/org/jivesoftware/util/cache/ConsistencyChecks.java (version bdb88c652208c895164f4a7595b6def84740a4dd)
• 

  Guus der Kinderen 20 Feb 2024 03b2f80e45e972b4345637c64d4c2dd68fcd78d6 m

  OF-2799: MUC occupant management for federated users in a cluster
  When clustering, every Openfire cluster node tries to maintain a minimal set of data describing rooms and occupants. The primary reason to do this is to be able to reconstruct data in case of a cluster node unexpectedly dropping out of the cluster. This data is (mostly) managed by the OccupantManager class.
  
  Prior to this commit, the OccupantManager associated every occupant with one or more cluster nodes (by cluster node ID). This commit changes that, in the following way:
  - Users of the local/non-federated XMPP domain are associated with exactly one cluster node: the one that they're 'physically' connected to (eg: where their TCP connection terminates).
  - Users of non-local/federated XMPP domains are no longer associated with any cluster node in particular.
  
  The prior association of federated users with specific cluster nodes makes little sense. It _was_ based on the node where their server-to-server connection terminated. That, however, is a poor choice. Server-to-server connections may be teared down due to inactivity (without this leading to occupants being removed from a MUC). It is perfectly acceptable for the s2s connection to be re-established to another cluster node. It's also possible to have multiple s2s connections, potentially to different nodes in the local cluster. It is reasonable to assume that _any_ cluster node is able to (re)establish s2s with the domain of a federated user. This removes more reasons for keeping a (set of) nodeID(s) for a federated occupant.
  
  It is assumed that drifts in data consistency are reduced/removed by no longer trying to maintain a occupant-to-clusternode binding for federated users.

  • xmppserver/src/main/java/org/jivesoftware/openfire/muc/MultiUserChatManager.java (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)
  • xmppserver/src/main/java/org/jivesoftware/openfire/muc/cluster/SyncLocalOccupantsAndSendJoinPresenceTask.java (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)
  • xmppserver/src/main/java/org/jivesoftware/openfire/muc/spi/MultiUserChatServiceImpl.java (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)
  • xmppserver/src/main/java/org/jivesoftware/openfire/muc/spi/OccupantManager.java (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)
  • xmppserver/src/main/java/org/jivesoftware/util/cache/ConsistencyChecks.java (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)
  • xmppserver/src/main/webapp/muc-room-cache.jsp (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)
  • xmppserver/src/test/java/org/jivesoftware/openfire/muc/spi/OccupantManagerTest.java (version 03b2f80e45e972b4345637c64d4c2dd68fcd78d6)