在队列深度 n 时，在使用队列消息时应用JMS选择器的算法时间复杂度是多少？特别是，每次读取是否为线性（O（n））？它是依赖于实现的（在JMS提供者上），它是否取决于所请求的字段？
（如果依赖于实现，我对Websphere MQ和Solace的行为特别感兴趣，但我欢迎处理任何特定JMS提供程序的答案，特别是如果您有描述复杂性的文档的链接！）。
动机：每条消息都有两个属性：invocationID和batchName。批处理包含多个调用。客户希望以两种方式之一消费消息;由invocationID或batchName提供。在生成消息时，我不知道它们将被消耗的方法。
这可以通过选择器实现：
invocationID=42
或者
batchName="reconciliation"
...我可以通过使用相关ID而不是自定义属性加快其中一个，但我担心另一个会保持缓慢。
答案 0 :(得分：3)
According to the docs，按顺序搜索消息。但是，WMQ会对MessageID和CorrelID字段进行索引。信息中心描述的行为如下：
从队列中选择消息需要WebSphere MQ顺序执行 检查队列中的每条消息。检查消息直到a 找到符合选择标准的消息，或者没有 更多要检查的消息。因此，消息传递性能会受到影响 消息选择用于深度队列。
在基于选择时优化深度队列上的消息选择 在JMSCorrelationID或JMSMessageID上，使用的选择字符串 表单JMSCorrelationID = ...或JMSMessageID = ...仅供参考 一个财产。
这种方法可以显着提高性能 选择JMSCorrelationID并提供边际性能 JMSMessageID的改进。
我希望更多地了解多路复用队列的要求。复杂的选择器将影响任何人的实现的性能，而使用具有更简单的选择器的多个打开句柄的替代方案与使用多个队列的应用程序代码没有区别。对于WMQ，当然，动态队列或许多永久定义的队列完全没有问题。很多时候，当我看到这个要求时，它来自使用某些其他传输的商店，其中性能严重下降并定义了许多队列，并且假设WMQ上也是如此。在其他情况下，Pub / Sub和持久订阅已满足要求。我并不是说这个要求没有有效的案例，只是想知道是什么驱使它。
答案 1 :(得分：2)
这完全取决于实施。许多JMS提供程序将消息存储在SQL数据库中，以便它们可以使用SQL进行选择器实现。在这种情况下，您必须查看您的特定情况如何映射到SQL。
对于WebSphereMQ - 选择器实现是JMSMessageID = sth和JMSCorrelationID = sth的O（log n），对于其他我没有具体知识的选择器实现。根据经验，它看起来像O（n）。
答案 2 :(得分：1)
使用WebSphere MQ版本7，选择器的实现被更改。使用v7 JMS客户端和v7 QueueManager，选择处理完成QueueManager端。使用v6 JMS客户端（或实际上是在其迁移中工作的v7客户端）模式，所有消息都会流向客户端进行处理。如果匹配消息的命中率很低，则会浪费很多精力。所以
使用v7，处理完成QueueManager端，因此只有匹配的消息才会发送到客户端。
请记住，QueueManager不像数据库那样维护消息属性的复杂索引。所以更简单的选择器就更好了。