This strategy is used by default 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.
In this strategy almost all packets are processed on the local cluster node. Only packets related to settings default options
(such as pubsub packets containing subelements options or default) will be forwared to all cluster nodes and processed on each of them. If packets will result in the node configuration, subscriptions
or affiliations changes other nodes will be notified to refresh node configuration/subscriptions/affiliations.
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.
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).
IQ stanzas which are stanza responsible for publication are processed on the local cluster node. In this case PubSub will able to properly send notifications (as notification are generated always on local user node, if user is connected, which reduces cluster network traffic).
presence- packets are delivered to every cluster node 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
pubsubsubelement) are processed on local node - PubSub related packets without PubSub node name are processed on the local node. If packets will result in the node configuration changes, other nodes will be notified to refresh node configuration.
- PubSub related packets containing subelements named
optionsordefaultwill be forwarded to all connected cluster nodes - remaining PubSub packets are processed on the local cluster node. If packets will result in the node configuration changes, other nodes will be notified to refresh node configuration.
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.
