Solace Cache Components

Solace Cache uses a distributed structure so that it can be scaled as necessary. Solace Cache is made up of the following components:

  • Solace Cache Instances, each installed on a standalone Linux server

  • Cache Clusters, which are groups of Solace Cache Instances that subscribe to the same set of topics

  • Distributed Caches, in which multiple Cache Clusters subscribe to different sets of topics

  • a Designated Router, which is an event broker that acts as the central repository and management point for the Distributed Cache configuration

The relationships between these components are shown in the following diagram:

Image showing the components described in the surrounding text.

Solace Cache Instances

A Solace Cache Instance is a single Solace Cache process running on a Linux server. For each Solace Cache Instance there is a corresponding management object that is created through the Solace Event Broker CLI on a Solace Appliance Event Broker or Solace Software Event Broker. From the perspective of the event broker, a Solace Cache Instance is a special client with some built-in configuration.

The initial configuration for a Solace Cache Instance is provided by a configuration file that the Solace Cache process reads when it starts up. The Solace Cache Instance also receives configuration information from the Designated Router after establishing a connection to it.

Solace Cache Instances listen for and cache live data messages that match the topic subscriptions configured for their parent Cache Cluster.

Each Solace Cache Instance in a Cache Cluster caches a published live data message if the following conditions are all met:

  • its topic matches a topic subscription configured for the Cache Cluster (wild card topics are supported)

  • the Solace Cache Instance is not administratively shut down

  • it does not violate configured constraints such as maximum memory or maximum number of topics

  • when an Ingress Message Plug-in is being used, the Plug-in function returns an operation code that directs the Solace Cache Instance to cache the message. For more information, see Ingress Message Plug-Ins.

Client cache requests are load-balanced between the Solace Cache Instances in a Cache Cluster.

Solace Cache Instance Interactions With the Designated Router

Each Solace Cache Instance uses a configuration file that provides parameters required to establish a connection with a host event broker (for example, username, password, event broker host to connect to). This configuration information is required on start up for the Solace Cache Instance to connect to and register with the Designated Router. (For more information on the content of the Solace Cache configuration file, see the configuration file template (sampleConfig.txt) provided with the SolCacheInstance package).

If the Solace Cache Instance successfully establishes a connection, the Designated Router’s Cache Manager downloads additional configuration information and topic information to the Solace Cache Instance.

If the Designated Router for a Solace Cache Instance goes offline or restarts, the Solace Cache Instance continues to run with the configuration that it last received from the Designated Router. Once the Designated Router comes back online, it resends the configuration information to the Solace Cache Instances that it is responsible for managing.

A Solace Cache Instance has the following additional interactions with the Designated Router:

  • Solace Event Broker CLI—Administrative and configuration changes made through the CLI on the Designated Router are sent between the Cache Manager and Solace Cache Instances.
  • Event—Events are generated on Solace Cache Instances and sent back to the Designated Router for reporting through the message bus.
  • Heartbeats—A heartbeat request is periodically sent by a Solace Cache Instance to the Designated Router to confirm the presence of each other. If three or more heartbeat requests are lost, then a Solace Cache Instance must reconnect and resynchronize its configuration with the Designated Router. It does not delete any of its cache content through this process unless it learns of topics no longer required to be cached. When it is trying to reconnect to the Designated Router, the Solace Cache Instance stays “in service” (that is, continues to service cache requests).

Removing Data Messages from Solace Cache Instances

Messages are removed from Cache Instances where they are cached when any of the following conditions arise:

  • A scheduled delete operation occurs.
  • An administrative delete message <topic> operation is issued from the Designated Router.
  • Configured limits, such as the lifetime or maximum number of messages per topic, are exceeded.
  • A change to the topic set defined on the Cache Cluster occurs at which time messages for topics cached outside of the configured topics set are deleted.
  • A Solace Cache Instance or its parent Cache Cluster or Distributed Cache is deleted.
  • Any termination of the Solace Cache Instance process. That is, the cache contents are volatile and are lost if the Solace Cache Instance process dies or is reset.

Cached messages are not removed from a Solace Cache Instance when the Solace Cache Instance or its parent Cache Cluster or Distributed Cache is shut down. However, when the Solace Cache Instance is subsequently enabled, or if an administrative start is performed (see Performing Solace Cache Administrative Tasks), and there is another active Solace Cache Instance in the Cache Cluster, the restarted Solace Cache Instance’s cached messages are removed and replaced with those of the Solace Cache Instance with which it is synchronized.

Cache Clusters

A Cache Cluster is a collection of one or more Solace Cache Instances that subscribe to exactly the same topics. There can be up to 16 Solace Cache Instances in a Cache Cluster. A Solace Cache Instance can belong to only one Cache Cluster.

Solace Cache Instances are grouped together in a Cache Cluster for the purpose of fault tolerance and load balancing. As published messages are received, the event broker message bus sends these live data messages to the Solace Cache Instances in the Cache Cluster. This allows client cache requests to be served by any of Solace Cache Instances in the Cache Cluster.

The message bus load-balances client cache requests between these Solace Cache Instances as determined by the priorities assigned to the individual Solace Cache Instances through the configuration file.

Each Cache Cluster in a Distributed Cache must use a different set of topic subscriptions; that is, the subscriptions assigned to each Cache Cluster must not overlap.

Each Cache Cluster can be configured through the Designated Router’s CLI or SEMP interface (see Configuring Cache Clusters). The Designated Router ensures that the configuration is propagated to all Solace Cache Instances in the Cache Cluster. Configuration parameters for the Cache Cluster are stored persistently in the Designated Router’s internal, non-volatile database, and are backed up and restored along with all the other configuration information for that event broker.

Designated Router

A Designated Router is a specific event broker through which a Distributed Cache and all of its associated Cache Clusters and Solace Cache Instances are configured and managed. An event broker can act as a Designated Router when a Message VPN is configured on that event broker (see Configuring Message VPNs).

The Designated Router is the central repository and management point for the Distributed Cache configuration. A network operator can perform Solace Cache configuration, management, and monitoring tasks on the Designated Router through the Solace Event Broker CLI.

The Designated Router uses an internal client, called the Cache Manager, to automatically provide the operations, administration, and management (OA&M) functionality required to manage many Cache Clusters and their associated Solace Cache Instances. For example, the Cache Manager is responsible for tasks such as:

  • Propagating configuration changes to a Cache Cluster, and ensuring that each Solace Cache Instance in the Cache Cluster has a consistent configuration

  • Disseminating topic space information throughout the Distributed Cache, so that each Cache Cluster has an up-to-date list of topics for its Solace Cache Instances to listen for and knows of the topics that Solace Cache Instances in all other Cache Clusters are listening for

  • Resynchronizing of Solace Cache Instances that disconnect and subsequently reconnect to the network

Distributed Caches

A Distributed Cache is a collection of one or more Cache Clusters that belong to the same Message VPN.

Each Cache Cluster in a Distributed Cache must be configured to subscribe to a different set of topics. This effectively divides up the configured topic space, to provide scaling to very large topic spaces or very high cached message throughput.

A Distributed Cache and all of its associated Cache Clusters are configured from the same Designated Router. The Cache Manager automatically ensures that each Solace Cache Instance in a Cache Cluster gets configured with:

  • The list of topics that the Cache Cluster (and subsequently its Solace Cache Instance) is responsible for

  • The lists of topics that are served by other Cache Clusters in the Distributed Cache, and the names of the Cache Clusters serving up those topics

Because Cache Clusters know of each other’s assigned topic sets, when a cache request is made to either the Distributed Cache or a specific Cache Cluster in the Distributed Cache, any matching cached messages in the Distributed Cache are returned, regardless of which Cache Cluster they are cached in.

The following diagram shows a show simple Distributed Cache example. The Distibuted Cache has 3 clusters:

  • Cache Cluster gateCrew has been configured to handle the topics flight/boarding/> and flight/doorsclosed/>

  • Cache Cluster groundCrew has been configured to handle the topics flight/baggageIn/> and flight/taxiing/>

  • Cache Cluster flightCrew has been configured to handle the topics flight/engineStart/> and flight/wheelsUp/>

Client applications have been set up to always send cache requests to gateCrew, although they could just as easily send their requests to groundCrew or flightCrew.

The following diagram shows a dataflow where all three Cache Clusters contain topics that match the cache request.

Image showing the flow of information within a Cache Clusteras described in the surrounding text

  1. The client application sends a cache request using a Solace Messaging API to the Cache Cluster gateCrew requesting messages with the topic flight/>.

  2. Cache Cluster gateCrew receives the request and performs these actions:

    1. Sends messages for the topics flight/boarding/> and flight/doorsclosed/> to the client application

    2. Sends a request for the topics flight/baggageIn/> andflight/taxiing/> to Cache Cluster groundCrew

    3. Sends a request for the topics flight/engineStart/> andflight/wheelsUp/> to Cache Cluster flightCrew

  3. Cache Cluster groundCrew receives the request and sends messages for the topics flight/baggageIn/> andflight/taxiing/> to the client application.

  4. Cache Cluster flightCrew receives the request and sends messages for the topics flight/engineStart/> andflight/wheelsUp/> to the client application.

Cache Requests and Responses

Client applications can use the Solace Messaging APIs for JCSMP, Java RTO, C, .NET, or JavaScript to make cache requests for topics. The cache requests must include the name of the Distributed Cache, Cache Cluster, or Solace Cache Instance to issue the request to and the topics requested.

Cache requests made using the JCSMP, Java RTO, C, and .NET APIs can either be synchronous or asynchronous. If the request is synchronous, then the API call blocks until the response is received (or a time-out occurs).

Cache requests made using JavaScript allow only asynchronous cache requests.

If a cache request is made to a Distributed Cache or a Cache Cluster, the request is delivered to one of the Solace Cache Instances in a Cache Cluster that are configured to listen for the same topics, and that single Solace Cache Instance responds to the cache request.