ACS-PubSub Partitioned Strategy

Short description
Description of processing
Rules of processing packets:
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.

Prev  Up  Next
  Home