Using SEMP to Monitor Solace Cache

SEMP is a request/reply protocol that uses an XML schema to identify all objects managed in a Solace event broker. Any object available through the Solace Event Broker CLI is also available through SEMP.

XML-encoded SEMP requests parallel the commands offered through the Solace Event Broker CLI, therefore, management applications can use SEMP requests and replies to manage and monitor Solace Cache. For example, when using Solace Cache, an application can regularly poll local any remote Solace Cache Instances by sending SEMP-based show commands and viewing the instances’ contents that are provided in the replies.

The SEMP XML-encoded commands and replies are either wrapped in HTTP requests and responses and sent over a TCP connection (SEMP Request over HTTP) to the management interface, or sent over the event broker message bus (SEMP Request Over Message Bus) using one of the Solace messaging APIs.

For information on using the event broker SEMP Request Over Message Bus service, see Using SEMP v1 to Manage and Monitor Event Brokers.

SEMP Polling Frequency Guidelines

An event broker supports a maximum SEMP polling rate of ten requests per second.

When you are using SEMP Request Over Message Bus service and a more-cookie is returned, the single page constitutes a single request. For information about oversized responses and the more-cookie, see SEMP v1 Paging.

The following SEMP requests should not be polled more than once every 30 seconds due to the large amounts of data that could be returned:

  • show cache-instance <name> remote status
  • show cache-instance <name> remote topics
  • show smrp subscriptions

The following SEMP requests should not be polled.

  • show queue <name> message-vpn <name> messages
  • show topic-endpoint <name> message-vpn <name> messages