在消耗来自队列的消息时,相对于队列深度n,应用JMS选择器的算法时间复杂度是多少？特别是,每次读取是否为线性(O(n))？它是依赖于实现的(在JMS提供程序上),是否取决于请求的字段？
(如果依赖于实现,我对Websphere MQ和Solace的行为特别感兴趣,但我欢迎处理任何特定JMS提供程序的答案,特别是如果您有描述复杂性的文档的链接!).
动机:每条消息都有两个属性:a invocationID和a batchName.批处理包含多个调用.客户希望以两种方式之一消费消息; 无论是通过invocationID还是通过batchName.在生成消息时,我不知道它们将被消耗的方法.
这可以通过选择器实现:
invocationID=42
要么
batchName="reconciliation"
...我可以通过使用相关ID而不是自定义属性来加快其中一个,但我担心另一个会保持缓慢.
根据文档，消息是按顺序搜索的。然而，WMQ 确实对MessageID和CorrelID字段建立了索引。信息中心对该行为的描述如下：
从队列中选择消息需要 WebSphere MQ 按顺序检查队列中的每条消息。检查消息，直到找到符合选择标准的消息或没有更多消息可供检查。因此，如果在深度队列上使用消息选择，消息传递性能会受到影响。
当选择基于 JMSCorrelationID 或 JMSMessageID 时，要优化深度队列上的消息选择，请使用 JMSCorrelationID = ... 或 JMSMessageID = ... 形式的选择字符串，并仅引用一个属性。
此方法显着提高了 JMSCorrelationID 选择的性能，并为 JMSMessageID 提供了边际性能改进。
我很想了解更多有关多路复用队列的要求。复杂的选择器将会影响任何人的实现的性能，而使用多个打开句柄和更简单的选择器的替代方案对于应用程序代码来说与使用多个队列没有什么不同。当然对于WMQ来说，动态队列或者很多永久定义的队列完全没有问题。我经常看到这个要求，它来自使用某些其他传输的商店，其中定义了许多队列，性能严重下降，并且假设 WMQ 上也是如此。在其他情况下，Pub/Sub 和持久订阅已经满足了要求。我并不是说这个要求没有有效的案例，只是想知道是什么推动了它。