Entries by Mathew Hobbis

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


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.… Read the rest

Configuring “Pre-Fetch” for Optimized Load-Balancing

Solace supplies a high performance guaranteed messaging solution that provides fully guaranteed messaging at very high message rates. In common with other vendors Solace provides a mechanism to improve the performance between the appliance and the API, limiting the effect of long rtt, etc. The  mechanism used is similar in functionality to the pre-fetch mechanism provided by other messaging vendors in that it allows the appliance to deliver batches of messages to the API.

In terms of implementation, Solace implements a sliding window mechanism for guaranteed message delivery in both directions between the appliance and the API. The use of a windowed acknowledgement scheme is well understood and is in use by a number of protocols that are widely used today, e.g. TCP. The approach means that the transmission of messages does not need to pause between messages while the message sender waits for an acknowledgement from the message receiver.… Read the rest