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 CLI, therefore, management applications can use SEMP requests and replies to manage and monitor Solace PubSub+. For example, when using PubSub+ Cache, an application can regularly poll local and 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 router SEMP Request Over Message Bus service, refer to Legacy SEMP.

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 constitute a single request. For information on oversized responses and the more-cookie, refer to 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