Tigase Advanced Clustering Strategy for PubSub (ACS-PubSub)

Tigase Team <team@tigase.com> v3.2.0-SNAPSHOT, 2020-08-11 :numbered:

Overview

ACS for PubSub allows seamless clustering of PubSub nodes across Tigase XMPP server cluster installation. ACS for PubSub is required for clustered PubSub deployments. If offers various strategies to handle distribution of traffic and nodes across the cluster, which allows fine-tune configuration of the deployment to individual needs.

Tigase ACS PubSub Configuration

In order to use ACS for PubSub, main Advance Clustering Strategy (ACS) is required. Once it’s enabled, clustered version of PubSub component will be selected by default during startup therefore it’s not required to configure it explicitly (make sure no other class is configured).

pubsub () {}

It’s also possible to explicitly configure the class with the following configuration:

pubsub (class: tigase.pubsub.cluster.PubSubComponentClustered) {}

With the above configuration default ACS PubSub clustering strategy will be used. In order to select different strategy you have to configure it’s class for strategy bean within pubsub component bean:

pubsub () {
    strategy (class: tigase.pubsub.cluster.PartitionedStrategy) {}
}

ACS PubSub Strategies

ACS-PubSub Partitioned Strategy

Short description

This is default stategy used by Tigase ACS - PubSub component in which particular PubSub node is handled by only one cluster node.

Description of processing

In this strategy all configuration of nodes of the same PubSub service JID is done by the same node of a cluster which is dynamically selected based on hash of service JID and number of connected nodes within cluster. After any change to node configuration is done, then node established for processing manipulation of this particular PubSub node is notified about details of the PubSub node and detailed changes made to it’s configuration. Remaining nodes do not require to know about changes.

Presences sent from users to PubSub service will be distributed to every node of a cluster.

Presence and IQ stanzas will be processed according to rules outlined below.

Rules of processing packets:
  • presence - packets are delivered to every cluster node as each cluster node is responsible for handling different PubSub nodes
  • message - is always processed locally
  • iq - cluster node which will process this packet is selected based on following rules:

    • non-PubSub packets (no pubsub subelement) are processed on local node
    • PubSub related packets without PubSub node name or packets that change PubSub node configuration (and contains node name and one of the following subelements: create, configure, default, delete) are processed on cluster node selected on hashcode derived from to attribute (service JID) and number of cluster nodes (this is done deal with concurrency issues between configuration changes)
    • remaining PubSub pockets (non-configuration and containing node name) are processed on cluster node selected based on to attribute of packet and name of PubSub node

Note

This strategy for every packet (with exception of presence) should force processing of packet on only one cluster node (presence will be processed on all nodes)

Note

This strategy will react on PubSub configuration node change and will send notification to cluster node responsible for processing items for PubSub node (selected based on to attribute of packet, name of PubSub node) to trigger cached PubSub node configuration refresh

Note

Result of packets generated on remote node should not be filtered, so if packet from one cluster node was forwarded to other cluster node for processing, then response packet should not be filtered when this PubSub clustering strategy is used.

ACS-PubSub Clustered Node Strategy

Short description

This stategy can be used by Tigase ACS - PubSub component in which each PubSub node is handled on every cluster node but each cluster node will contain only partial information about user connections. This way strategy is better suited for deployments with PubSub nodes having a lot of subscribers. The benefit of using ClusterNodeStrategy in this case is reduced network traffic on cluster connections, as most of notifications and retrieval of items will be handled on the same cluster node to which user is connected.

Description of processing

In this strategy all configuration changes of pubsub nodes within same PubSub service JID are handled on the same node of the cluster (dynamically selected based on hash of service JID and number of connected nodes). After making changes to node configuration every cluster node is notified about this particular node identification (node name as well as service JID to which it belongs) and they refresh it’s cached configuration.

Presences sent from users to PubSub service will be delivered to every node of a cluster.

If every other IQ stanza sent to PubSub service which is does not change configuration of a node and is item publication stanza then this stanza will always be processed on local node (as data retrieval/removal may be done only on one node as items are not cached).

For IQ stanzas which are stanza responsible for publication of an item is forwarded for processing to every cluster node as only in this case PubSub will able to properly send notifications (as notification are generate always on local user node which reduces cluster network traffic).

Rules of processing packets:
  • presence - packets are delivered to every cluster node as each cluster node is responsible for handling different PubSub nodes
  • message - is always processed locally
  • iq - cluster node which will process this packet is selected based on following rules:

    • non-PubSub packets (no pubsub subelement) are processed on local node
    • PubSub related packets without PubSub node name or packets that change PubSub node configuration (and contains node name and one of the following subelements: create, configure, default, delete) are processed on cluster node selected on hashcode derived from to attribute (service JID) and number of cluster nodes (this is done deal with concurrency issues between configuration changes)
    • PubSub item publication packets (must contain node name attribute within pubsub element) are delivered to all cluster nodes and each cluster node generates notifications about item publication to users connected to that particular cluster node.

Note

This strategy will react to PubSub configuration node change and will send notification to every cluster node (as every cluster node is responsible for processing items for every PubSub node) to refresh particular PubSub node configuration.

Note

Result of processing of packets generated on remote node should be filtered if packet was also processed on local node, so if packet from one cluster node was forwarded to other cluster node for processing but was not processed locally, then response packet should be filtered when this PubSub clustering strategy is used.

In a nutshell

Partitioned Strategy assigns PubSub node to cluster node and handle all processing on that particular cluster node (configuration change, generating notification packets), Clustered Node Strategy distributes processing of nodes across cluster - each cluster node has complete knowledge of all PubSub nodes but performs processing that corresponds only to itself (i.e. generates notifications only for users connected to this particular node).