Какова алгоритмическая временная сложность применения JMS-селекторов при потреблении сообщений из очереди по отношению к глубине очереди n? В частности, является ли он линейным (O (n)) на чтение? Это зависит от реализации (от поставщика JMS) и зависит от того, какие поля запрашиваются?
(если зависит от реализации, меня особенно интересуют поведение WebSphere MQ и Solace, но я приветствую ответы, которые касаются любого конкретного JMS-провайдера, особенно если у вас есть ссылки на документацию, описывающую сложность!).
Мотивация: каждое сообщение имеет два свойства: a invocationID
и a batchName
. Пакет состоит из нескольких вызовов. Клиенты хотят потреблять сообщения одним из двух способов; либо invocationID
, либо batchName
. В момент создания сообщений я не знаю, каким способом они будут потребляться.
Это может быть реализовано с помощью селекторов:
invocationID=42
или
batchName="reconciliation"
... и я могу ускорить один из них, используя идентификатор корреляции вместо настраиваемого свойства, но я обеспокоен тем, что другой будет оставаться медленным.