Warning
This strategy is now deprecated.
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.
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.
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 nodesmessage
- 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 fromto
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 onto
attribute of packet and name of PubSub node
Note
This strategy for every packet should force processing of packet on only one cluster node
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.