Using SEMP to Monitor PubSub+ Cache

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

XML-encoded SEMP requests parallel the commands offered through the Solace CLI, therefore, management applications can use SEMP requests and replies to manage and monitor PubSub+ Cache. For example, when using PubSub+ Cache, an application can regularly poll local any remote PubSub+ 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