whether the queue messages objects returned in the SEMP response list follow a specific order

rayleeustc_ll
rayleeustc_ll Member Posts: 7 ✭✭

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

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin

    I'm pretty sure it's oldest to newest. In SEMPv1 you can ask for newest-to-oldest, but I don't think you can do that (yet?) with SEMPv2.

    What are you trying to do?

  • rayleeustc_ll
    rayleeustc_ll Member Posts: 7 ✭✭

    really helpful, very appreciating

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin

    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..?

  • Subhiksha
    Subhiksha Member Posts: 1

    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

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin

    @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.