Approximating Queue Semantics in Non-Persistent Messaging

Solace provides the ability to approximate queue semantics within the non-persistent publish and subscribe environment. This is useful for a number of reasons –

1. It operates at rates an order of magnitude higher than persistent messaging, i.e. a million messages per second rather than 100k messages per second.
2. It allows load balancing of requests across a number of instances providing services to the application, e.g. entitlements checking, grid processing engines.
3. It allows fault tolerance of services to the application, e.g. entitlements checking, grid processing engines.
4. It allows JMS users to effectively build applications that do not want persistence, or durability, but that do want to use queue semantics rather than topics (JMS does not allow you to name temporary queues).
5. On application removal there is no state kept within the message transport domain

Deliver-To-One

Figure 1: Direct Messaging – DTO Load Balancing from a Topic

Deliver-To-One (DTO) is a Solace Extension to the standard Publish and Subscribe pattern. It allows the Solace appliance to mimic queue behaviour in the  pub/sub messaging world where queues do not formally exist. The application can use DTO to provide the fail-over and load-balancing behaviours that are typical of queues.

Deliver-To-One is a property of the published message, i.e. the publisher must flag a message for delivery to a single client by setting the DTO property to true. The way subscribers receive the messages that are sent with the DTO flag  set are dependent on their ‘connection priorities’:

Figure 2: Direct Messaging – DTO Fail-Over from a Topic

1. If all of the subscribing clients connect with the same priority then this is the equivalent of a Non-Exclusive queue and messages will be load-balanced across the connected clients.
2. If clients connect using different priorities then this is the equivalent of an Exclusive queue and the highest priority client will be the only client to receive messages.

The two modes of DTO operation are shown in the accompanying figures. It is also worth noting  that the two modes are NOT mutually exclusive. It is possible, although unusual, to mix modes, i.e. 6 clients connect, 3 at priority 1 and 3 at priority 2.

The priorities used by subscribers, to determine their role in DTO, are supplied as session properties to the SDK.

There is one important limitation compared to queues in the persistent domain. There can be only one instance of a specific topic that is “deliver-to-one” within a VPN. This means that there is no ability to publish to a single topic and have it applied to two separate DTO groups.

Deliver-To-One-Override

DTO allows a user to mimic queue behaviour using extensions to standard publish and subscribe mechanisms. However, in doing so it prevents certain applications from using the same mechanisms to take a copy of the message for auditing, replay or monitoring purposes.

To allow these applications to still function solace also provides a Deliver-To-One-Override function that may be applied as part of the subscription. When the subscription flag is applied the clients that override DTO will receive a copy of the message in addition to the client that is part of the DTO group and will receive the message as part of the DTO process.

Generic Use-Cases

There are a number of use-cases that can make use of the DTO facility

1. Computing Grid Job Distribution
   1. Client disconnection as well as job failure status would result in the job being resubmitted by the scheduler.
   2. Grid nodes report job in progress allowing Grid monitor to detect lost jobs and arrange resubmission.
   3. In the event that a processing engine restarts and reconnect to the appliance there is no ‘stale’ state, in terms of messages to be delivered, that must be cleared before processing can resume.
   4. Typically suitable for shorter durations jobs where re-submission of a failed job is acceptable when weighed against a simplification of application logic.
2. Distribution of Incoming Requests
   1. Service agents listen on, and Clients send incoming requests to, a shared topic for the initial contact.
   2. The Solace appliance distributes requests across the available service agents.
   3. This provides resilience and also provides the ability to deploy more service agents to cope with increased loads, for long-term growth or simply to cope with short-term spikes in traffic.
   4. Service Agents respond on the incoming messages reply-to
   5. In the message exchange is multi-part then the service agent my include its own unique topic for subsequent message exchanges thus supplying a ‘stickiness’ to the distribution.