從隊列中消耗消息時應用JMS選擇器的算法時間複雜度，相對於隊列深度n？特別是，每次讀取是線性的（O（n））？它是依賴於實現的（在JMS提供者上），並且它取決於被請求的字段？我對Websphere MQ和Solace的行爲特別感興趣，但是我歡迎與任何特定JMS提供者打交道的答案，特別是如果你有指向描述複雜性的文檔的鏈接！）。JMS選擇器如何按照隊列深度進行縮放？
動機：每封郵件有兩個屬性：invocationID和batchName。批處理由多個調用組成。客戶希望以兩種方式消費消息;通過invocationID或batchName。在產生信息的時候，我不知道他們將被消費的方法。
這可以通過選擇來實現：
invocationID=42
或者
batchName="reconciliation"
...我可以通過使用相關ID，而不是一個自定義屬性加速這些了一個，但我擔心對方會保持緩慢。
According to the docs，按順序搜索消息。 WMQ不會索引MessageID和CorrelID字段。 Infocenter描述如下行爲：
從隊列中選擇消息需要WebSphere MQ按順序 檢查隊列上的每條消息。檢查消息，直到找到與選擇標準匹配的 消息或者沒有 更多要檢查的消息。因此，如果在深隊列中使用 消息選擇，則消息傳遞性能受損。
要在深隊列優化消息選擇時選擇基於 上JMSCorrelationID或JMSMessageID按，使用 形式JMSCorrelationID = ...或JMSMessageID按= ...和參考唯一 一個屬性的選擇字符串。
該方法爲JMSCorrelationID上的 選擇性能提供了顯着的性能改進，併爲JMSMessageID提供了改進的邊際性能 。
我想了解更多有關複用隊列的需求。一個複雜的選擇器將影響任何人的實現的性能，而使用多個打開的句柄和更簡單的選擇器的替代方案與使用多個隊列的應用程序代碼沒有區別。對於WMQ當然，動態隊列或許多永久定義的隊列完全沒有問題。很多時候，當我看到這個要求時，它來自那些使用某些其他傳輸方式的商店，其中性能需要嚴格的潛水並定義了許多隊列，並且有一個關於WMQ也是如此的假設。在其他情況下，Pub/Sub和持久訂閱已滿足要求。我並不是說沒有這個要求的有效案例，只是想知道是什麼驅使它。
很好的答案，謝謝你的鏈接！選擇器本身不會很複雜（可能只是在一個屬性上是平等的） - 它不一定就是相關性！ （已經使用過）。 – bacar
我的選擇器並不複雜;我已經添加了一些關於我的動機的細節，並刪除了多路複用的提及，因爲它有點不準確。 – bacar
感謝您的澄清！這聽起來像是一個Pub/Sub問題。可以使用管理訂閱將消息的一個副本放置在隊列中，客戶端可以通過CorrelID檢索消息。對其他房產感興趣的客戶可以簡單地訂閱它作爲主題。這些可以是動態訂閱或持久訂閱，但是因爲選擇將在發佈時進行評估，所以每個客戶端將只獲取它感興趣的消息並且可以簡單地讀取其訂閱隊列FIFO。當然，如果選擇在運行時改變，這是行不通的。 –
這一切都取決於實施。許多JMS提供程序將消息存儲在SQL數據庫中，以便他們可以使用SQL進行選擇器實現。在這種情況下，您必須查看特定案例如何映射到SQL。
對於WebSphereMQ--選擇器實現是O（log n）JMSMessageID = sth和JMSCorrelationID = sth，對於其他我沒有具體的知識。但從經驗來看，它看起來像O（n）。
對於WebSphere MQ V7，選擇器的實現已更改。使用v7 JMS客戶端和v7 QueueManager，選擇處理完成QueueManager端。使用v6 JMS客戶端（或者實際上是一個工作在它的遷移模式的v7客戶端）模式，所有消息都被傳送到客戶端進行處理。如果匹配消息的命中率很低，則會造成很大的浪費。所以
隨着v7的處理完成QueueManager端，所以只有匹配的消息發送到客戶端。
請記住，QueueManager不會像數據庫那樣維護消息屬性的複雜索引。所以簡單的選擇器就更好了。
謝謝。所有有用的信息，但無論我使用v6還是v7，它都可能是線性的 - 也就是說，雖然v7可以在服務器而不是客戶端上完成工作，但效率可能更高，但所做的工作仍可能涉及掃描隊列中的每條消息（O（n））找到與選擇器匹配的一個。 – bacar
偉大的問題！我懷疑這很難得到一個很好的答案，但對於做出某些架構決策顯然是非常重要的。 –
謝謝@TomAnderson！ – bacar