🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
whether the queue messages objects returned in the SEMP response list follow a specific order
When we call the SEMP API to fetch message information from a queue using the Get API /msageVpns/{msgVpnName}/queues/{queueName}/msgs, it returns a list of Queue Message objects. Is there a certain order that these message objects follow in the response list? Also, is it safe to assume that the first message object in the list is always the oldest message in the current queue?
Comments
-
really helpful, very appreciating
0 -
Note that this command is not super "lightweight"... grabbing a bunch of message IDs and related metadata out of a queue. I wouldn't use this for active monitoring (e.g. polling 100s of queues for their messages every 10 seconds or something). This is more useful for troubleshooting. In general.
So yeah, I'll ask again: what are you trying to do? Maybe there's another/different/better way to achieve..?
0 -
our use case is- we want to get the timestamp of the oldest message or in other words, we want to identify queues which are running full. 2 cases can occur, no consumer is connected to fetch the messages, the 2nd problem is, consumer is connected, but he can not process the incoming messages, because there are to many messages produced. Both cases we want to identify
0 -
@Subhiksha ok, so for monitoring. There are probably better ways to check if a queue is filling up rather then polling each individual queue for its messages and checking the timestamp of its oldest message. For example, polling all queues at once with wildcards:
- You can see if a queue is filling up because its number of spooled message and spool usage will be increasing
- You can see the queue rates, to see if egress rate < ingress rate for a sustained time
- You can see what the oldest/lowest message ID in a queue is, and see if it is changing/stuck even if there are lots of new messages going into the queue.
- There is also Syslog eventing: when a queue crosses the 25% full mark, the broker will emit a QUEUE_HIGH alert to Syslog. You can configure an external Syslog destination such as Splunk or Syslog-NG to be notified of his alert.
I'm aware we don't have great documentation on best practices for monitoring. Maybe this is something we can address in the future.
0