Pub/Sub Messages Behaviour and Properties

A message contains the actual data object which is sent by the publisher and delivered to the interested subscribers for the topic. For example, some subscribers are interested in order details of a company so that it can be processed further by the subscribers. A topic is created to publish messages for Order and all subscribers interested will subscribe to it. Once the publisher publishes the message to the topic, the registered subscribers are notified that a message pertaining to their interest has been published.

In case of multiple messages, the messages are stored in a sequence in a queue in the topic, however, ordered delivery of messages is not guaranteed.

Note

The same message can be assigned to multiple topics. This is uniquely identified through an auto generated ID.

Message Properties

Message Delivery Options

You can specify the delivery options through a DeliveryOption enum, on how a message can be delivered. Following are the two delivery options provided by NCache.

All: Delivers message to all registered subscribers, if no subscriber has been registered, it will return without any failure acknowledgment. Message will be sent to any subscriber when it registers on topic; unless message expiration has not occurred.
Any: Delivers message to some of the registered subscribers. If acknowledgement is not received, the message is reassigned to another subscriber till it reaches its expiration time limit.

Message Behavior

Message Invalidation

Eviction: If eviction is enabled on cache, messages will also be evicted from topics using LRU based policy. However, LRU in case of Pub/Sub becomes FIFO, as messages are stored in queue like structure in a topic. Note that this feature only applies to Enterprise Edition.
- If the cache being used for Pub/Sub transactions is the same as the one being used for normal caching, the first priority of eviction will always be cache data.
- If cache data is not available for eviction, then messages will be evicted. This will ensure that messages will only be evicted in extreme cases or when cache is dedicated for Pub/Sub only.
Expiration: Expiration can be enabled on messages as with cache items. The messages will be expired from the cache as soon as the expiration interval has passed and uses the same cleaning interval mechanism. Detail for expiration in messages has been provided later in the chapter.
Clear Cache: Messages are removed along with cache items once it is cleared.
Cache Restart: A topic is deleted once the cache is restarted. Hence, any messages contained within it are also invalidated.

Storage and Distribution

Messages are distributed among nodes based upon topologies.
- For Partition of Replica and Partitioned topologies, hash-based distribution is used.
- For Replicated topology, messages are replicated to all nodes of clustered cache. However, the coordinator node is responsible for message manipulation.
If message store is near eviction, an event is logged for stating store is full and eviction is started.
Messages have an overhead on cache memory. Hence, message size is considered while calculating the cache size.

Encryption and Compression

This feature is only available for Enterprise Edition.
Encryption and compression configured at cache level also apply to topic message payload.

State Transfer

In case of state transfer, when messages move to another node in the cluster, the node where message is finally stored is responsible for delivery.
Note that there is a chance of the client application receiving duplicate messages during state transfer.

Additional Resources

NCache provides sample application for Pub/Sub at:

GitHub
Shipped with NCache: %NCHOME%\samples\dotnet\PubSub