QoS

MigratoryData offers two levels of Quality of Service (QoS) for message delivery:

These QoS levels should be specified through the configuration of a cluster of MigratoryData servers, and through the way each message is published by the client API.

Clustering with a particular QoS level

Both clustering modes offer reliable message delivery and fault tolerance, including automatic client reconnection if the connection between a client and a cluster member goes down or if a cluster member goes down. However, Guaranteed Message Delivery offers a better quality of service as detailed in the Guaranteed Message Delivery section below.

Standard Message Delivery

The clients communicate with the MigratoryData server using the TCP protocol at the transport layer which is a reliable protocol. Also, MigratoryData implements high availability for both QoS levels. Therefore, using a cluster configured to use Standard Message Delivery will continue to work even if a sudden failure occurs, such a cluster member goes down or the connection between a client and the server is broken.

In this way, both clustering mode using Standard Message Delivery and Guaranteed Message Delivery offer reliable message delivery. However, clustering with Guaranteed Message Delivery offer even more reliability as detailed below.

Guaranteed Message Delivery

Guaranteed Message Delivery offers something more than Standard Message Delivery as follows:

• With Standard Message Delivery, when a client reconnects to another cluster member after a failure, it will get only the snapshot messages available for its subscribed subjects (as well as any subsequent message for its subscribed subjects)
• With Guaranteed Message Delivery, when a client reconnects to another cluster member after a failure, it will get not only the snapshot messages available for its subscribed subjects, but also the messages received by the cluster for its subscribed subjects during the fail-over period (as well as any subsequent message for its subscribed subjects)

The following diagram shows an example of fail-over recovery with Standard Message Delivery enabled. Note that when the client reconnects to the server B at 10:12:20, it will only get the snapshot message available for the subject X at that time (which is the latest message for the subject X with the flag retained on true). Therefore, it will not get one of the two messages which occurred during the fail-over recovery period, i.e. the message at 10:12:05.

The following diagram shows an example of fail-over recovery with Guaranteed Message Delivery enabled. Note that when the client reconnects to the server B at 10:12:20, it will get not only the snapshot message available for the subject X at that time, but all messages received during the fail-over recovery period, including the message at 10:12:05.

Therefore, with Standard Message Delivery, only the snapshot message for each subject is kept in memory in each cluster member and it is available after a client reconnection. However, with Guaranteed Message Delivery, not only the snapshot message is retained but also a configurable history of the latest published messages for each subject. Learn more in the History section.

Messaging with a particular QoS level

As learned in the Messages section, each message has a property qos. This implies that the client API can generate and publish a message with a specific QoS level, namely STANDARD or GUARANTEED.

It is important to note that in the case of Standard Message Delivery clustering, employing either of the two QoS levels through the client API will still produce a QoS level of STANDARD. However, in the event of Guaranteed Message Delivery clustering, using the QoS level STANDARD while publishing a message that doesn’t require retention in history could conserve resources.