Verifies the integrety of the projects, as builds are executed immediately after a code change was detected. This plan provides no artifiacts (use a nightly build instead).
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.
