Selectors - discouraged, but is there field that would be fast?

Solace Event Broker
, ,
1

Hi,

Based on documentation, I can see that selectors are slow (Selectors ). I imagine that broker has to scan RAM and potentially disk when consumer is fetching messages.

  1. Are all selectors equivalent (user properties vs ApplicationMessageId) with regards to scan performance assuming this is same type comparison. Seeking guidance if by any chance I can easily browse/lookup message by known field is indexed better.
  2. Why messageId is not available as selector?

Thanks,

Radek

2

Hi there, I’m Solly AI, I generate responses to your questions using the power of the Solace Agent Mesh:

Please remember that AI technology can make mistakes so ensure that you read our Disclaimer.

AI Generated responses are a work in progress, your help in evaluating my response would be awesome! If my response makes sense, please mark it as a solution or give a :+1:. If my response doesn’t make sense for your topic, please react to it with a :shaking_face:.

Based on the provided documentation, I’ll analyze the performance implications of different selector types and explain why messageId isn’t available as a selector.

Performance Impact Analysis:

  1. User Properties vs ApplicationMessageId (mi):
  • Both user properties and ApplicationMessageId are stored in the message’s header fields and can be used as selectors
  • The documentation doesn’t indicate any performance difference between selecting on user properties vs ApplicationMessageId
  • The key performance consideration is that ANY selector usage requires:
    • Retrieving each message (potentially from disk)
    • Evaluating message contents against the selector expression
    • For deep queues, this can take several seconds to find matching messages
    • Large messages take longer to evaluate
    • Can impact overall event broker message spool performance
  1. Why messageId isn’t available:
    The documentation shows that JMSMessageID maps to mi (ApplicationMessageId) in the Solace identifier mapping, but doesn’t explicitly mention messageId. This suggests that messageId is not exposed as a selector field - however, the documentation doesn’t explicitly state why this design choice was made.

Key Performance Recommendations:

  1. Avoid selectors whenever possible
  2. Use topic matching instead of selectors where possible:
    • Include selector properties within topic hierarchy
    • Use topic subscriptions and exceptions for filtering
    • Topic filtering occurs before messages enter queues, avoiding performance impact
    • Topic subscriptions support wildcards and prefix matching
    • Can implement AND, OR, NOT operations using topic subscriptions

Sources:

3

Hello Radek,

I believe that you are looking at selectors as another way to solve the async ack problem. This is an interesting question still and I will offer my thoughts on it.

Selectors are a JMS concept (JMS 1.1, section 3.8.1.1) and Solace support for them is defined to support JMS, which is selecting on fields that may be set by a publisher and potentially known to the consumer through some meta knowledge of the whole system. Therefore, patterns or exact strings on JMS properties and user properties are expected. The solace assigned message-id is not something that can be selected on as it doesn’t fit the JMS model.

The performance issues with selectors are two-fold. First parsing out the JMS properties from each message is more expensive than looking for fields in Solace messages directly (like the solace assigned message-id). Secondly and potentially more significant, is searching the queue for messages that match the selector. The cost of this search is at least linear with the number of messages on the queue.

Finally as a solution to your async-ack problem, it is probably a non-starter as you can’t select on the solace assigned messge-id (the spooler-msg-id) and as with semp, the spooler-msg-id is not known to the application.

Regards,

Ragnar