Build: #1952 was successful Scheduled with changes by daryl herzmann <akrherz@iastate.edu>

Stages & jobs

  1. Build and Package

  2. Copy to Website

Build result summary

Details

Completed
Queue duration
< 1 second
Duration
49 minutes
Labels
None
Revision
5d62ef9df1fcda29a95ca445aa85643c9d557df0
Total tests
1396
Successful since
#1938 ()

Tests

Code commits

Author Commit Message Commit date
daryl herzmann <akrherz@iastate.edu> daryl herzmann <akrherz@iastate.edu> 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 Guus der Kinderen df87d2ba10160353b14d0b5ba31804bea2ce14fb m OF-2799: Fix Consistency Checks for updates in previous commit (compare collections based on content only, not on order).
Guus der Kinderen Guus der Kinderen 46232c2998e974eab7b971f52b5674f23cb6a5a2 m Applied IDE-suggested improvements to ConsitencyChecks (no functional changes)
Guus der Kinderen Guus der Kinderen bdb88c652208c895164f4a7595b6def84740a4dd m OF-2799: Fix Consistency Checks for updates in previous commit.
Guus der Kinderen Guus der Kinderen 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.

Jira issues

IssueDescriptionStatus
Unknown Issue TypeOF-2799Could not obtain issue details from Jira