有选择地出队的消息是否保持FIFO顺序(MQ)?

4
使用JMS和WebSphere MQ时,如果我使用消息选择器进行有选择地出队,而且有几个消息具有相同的选择条件,那么我是否保证出队与之匹配的第一条消息?
例如,给定一个包含以下消息的队列:
1. {color: pink, name: alice} 2. {color: blue, name: bob} 3. {color: red, name: charlie} 4. {color: blue, name: doug}
如果我使用选择器color='blue'进行出队,那么我是否保证出队{color: blue, name: bob}?或者是否有可能得到{color: blue, name: doug},即使它在队列深度中更远?
2个回答

3
请参考不同 WMQ 连接工厂实现的 RESCANINT 属性。从手册中得知:
当点对点领域中的消息消费者使用消息选择器来选择它想要接收的消息时,WebSphere MQ JMS 客户端按照队列的 MsgDeliverySequence 属性确定的顺序在 WebSphere MQ 队列中搜索合适的消息。当客户端找到合适的消息并将其传递给消费者时,客户端会从队列的当前位置恢复搜索下一个合适的消息。客户端以这种方式继续搜索队列,直到达到队列的末尾或者时间间隔(以此属性的值为确定)过期为止。在每种情况下,客户端都会返回到队列的开头继续搜索,并开始新的时间间隔。
这个想法是在一个非常繁忙的具有优先级投递的队列中,一些更高优先级的消息可能会出现在队列的较高位置,然而消费者却无法看到它们,除非从队列头部开始查找。当光标到达末尾或RESCANINT时,光标将被重置为队列头部。设置RESCANINT可以调整选择器在查找这些高优先级消息时的响应速度。

RESCANINT不仅适用于FIFO投递。另一种情况是如果有多个线程具有重叠的选择条件,则其中一个线程可以持有锁定的消息,然后释放它。虽然该消息可能符合第二个线程的条件,但如果该线程已经通过队列中的该位置,则需要到达队列末尾或RESCANINT已过去才能重新启动光标以查找该消息。

重新扫描间隔以毫秒为单位,默认为5000。接受任何正整数值,但太低的值会导致光标在消耗任何消息之前不断重置而导致抖动。

作为实际问题,如果队列是FIFO且您只有一个读取器符合消息的条件,则无论RESCANINT设置为何值,您都会按顺序接收到消息。如果要严格保留消息顺序,则还需要考虑一些其他因素,如Sequential retrieval of messages所述。这些归结为在考虑通道、同步点等时,消息仅具有从生产者到消费者的一条路径。

+1,多么详尽的回答。考虑到所问的简单情况(所有消息具有相等的优先级和一个读取器),回答是“是的,它是FIFO顺序”,对吗? - MaDa
2
OP没有提到有多少个线程,是否存在网络跳跃或其他可能会干扰顺序的问题,因此我想提供一些关于内部和依赖关系的信息。此外,涉及的问题固有于异步消息传递,但不同的提供者会以稍微不同的方式解决这些问题。因此,即使答案的本质是“是的,它是FIFO”,了解它是可调的以及如何影响答案也很重要。 - T.Rob
该URL似乎已经失效。这是关于第7版的链接:https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.0.1/com.ibm.mq.csqzae.doc/ic11080_.htm - user3714601

2
请参阅章节“从队列中检索消息的顺序”和以下内容:“获取特定消息”。
总结:忽略FIFO顺序获取消息的唯一方法是通过消息ID或关联ID获取特定消息。队列也可以配置为按FIFO +优先级顺序传递,但这不是您考虑的选项。最后,如果消息被分组,消息排序就会变得复杂,但这也不是您的情况。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接