java - JMS 选择器如何随队列深度扩展?

标签 java jms ibm-mq

关于队列深度 n,在使用队列中的消息时应用 JMS 选择器的算法时间复杂度是多少?特别是,每次读取是线性的 (O(n)) 吗?它是否依赖于实现(在 JMS 提供程序上),是否取决于请求的字段?

(如果依赖于实现,我对 Websphere MQ 和 Solace 的行为特别感兴趣,但我欢迎处理任何特定 JMS 提供程序的答案,特别是如果您有指向描述复杂性的文档的链接!)。

动机:每条消息都有两个属性:invocationIDbatchName。一个批处理由多个调用组成。客户希望以两种方式之一使用消息;通过 invocationID 或通过 batchName。在产生消息的那一刻,我不知道它们将通过哪种方式被消费。

这可以通过选择器实现:

invocationID=42

或者

batchName="reconciliation"

...我可以通过使用相关 ID 而不是自定义属性来加快其中一个的速度,但我担心另一个会保持缓慢。

最佳答案

According to the docs ,按顺序搜索消息。然而,WMQ 确实索引了 MessageIDCorrelID 字段。信息中心描述的行为如下:

Selecting messages from a queue requires WebSphere MQ to sequentially inspect each message on the queue. Messages are inspected until a message is found that matches the selection criteria or there are no more messages to examine. Therefore, messaging performance suffers if message selection is used on deep queues.

To optimize message selection on deep queues when selection is based on JMSCorrelationID or JMSMessageID, use a selection string of the form JMSCorrelationID = ... or JMSMessageID = ... and reference only one property.

This method offers a significant improvement in performance for selection on JMSCorrelationID and offers a marginal performance improvement for JMSMessageID.

我很想了解更多关于多路复用队列的要求。复杂的选择器会影响任何人的实现性能,使用多个打开句柄和更简单的选择器的替代方案与使用多个队列的应用程序代码没有什么不同。当然对于WMQ来说,动态队列或者很多永久定义的队列是完全没有问题的。很多时候,当我看到这个需求时,它来自使用某些其他传输的商店,在这些传输中,性能严重下降,定义了许多队列,并且假设这在 WMQ 上也是如此。在其他情况下,发布/订阅和持久订阅已满足要求。我并不是说这个要求没有有效的案例,只是想知道是什么插入了它。

关于java - JMS 选择器如何随队列深度扩展?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13446072/

相关文章:

java - Android如何使用retrofit传递模态类和参数数组

java - JMS onMessage() 和并发

java - 我去哪里购买 Java EE jar?

jms - IBM WebSphere MQ 请求/回复场景

ibm-mq - 命令提示符中的 MQ

java - 使用 MySQL 更改预计值

java - 在 list 和运行时允许读写权限后权限被拒绝

java - 可选的 throw 需要 NPE 的 throws 声明

java - PooledConnectionFactory 处于无限重新连接循环中

java - com.ibm.mq.MQException : MQJE001: Completion Code '2' , 原因 '2035'