ACS-PubSub Partitioned Strategy


This strategy is now deprecated.

Short description

This is the simplest strategy that can be 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 handled on the local node of the cluster and then distributed to every node of a cluster as events.

Messages sent from users to PubSub service will be handled on the local node of the cluster.

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

Rules of processing packets:
  • presence - packets are processed on the local cluster node and then other cluster nodes are notified about changed presence 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:

    • CAPS query responses will be processed on the local node
    • 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 packets (non-configuration and containing node name) are processed on cluster node selected based on to attribute of packet and name of PubSub node


This strategy for every packet should force processing of packet on only one cluster node


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


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.