使用 JMS 和 WebSphere MQ，如果我使用消息选择器有选择地出队，并且有几条具有相同选择标准的消息，我是否保证将第一个匹配的消息出队？
例如给定一个带有消息的队列
{color: pink, name: alice}{color: blue, name: bob}{color: red, name: charlie}{color: blue, name: doug}如果我使用选择器color='blue' 出列，我是否保证会出列{color: blue, name: bob}？或者我有机会获得{color: blue, name: doug}，即使它在队列深度更远？
【问题讨论】：
请参考不同 WMQ 连接工厂实现的RESCANINT 属性。来自手册：
当点对点域中的消息消费者使用消息时 选择器来选择它想要接收的消息，WebSphere MQ JMS 客户端在 WebSphere MQ 队列中搜索合适的消息 由 MsgDeliverySequence 属性确定的序列 队列。当客户端找到合适的消息并将其传递给 消费者，客户端继续搜索下一条合适的消息 从它在队列中的当前位置开始。客户继续搜索 以这种方式排队，直到它到达队列的末尾，或者直到 以毫秒为单位的时间间隔，由值确定 此属性，已过期。在每种情况下，客户端都返回到 队列的开始以继续搜索，以及新的时间间隔 开始。
这个想法是，在一个非常繁忙的优先传递队列中，一些具有更高优先级的消息可能在队列中显示得比选择器的当前位置更高。理论上应该首先消费更高优先级的消息，但消费者不会看到它，除非它从队列的头部寻找。游标在到达末尾或到达 RESCANINT 时重置到队列的头部。 RESCANINT 的设置允许调整您希望选择器在查找这些更高优先级消息时的响应速度。
RESCANINT 并非特定于 FIFO 交付。另一种可能发生这种情况的情况是，如果有多个线程具有重叠的选择标准。在这种情况下，一个线程可以锁定一条消息，然后释放它。尽管消息可能适合第二个线程，但如果该线程已经通过了队列中的该位置，则需要到达队列末尾或经过 RESCANINT 重新启动游标以查找消息。
重新扫描间隔以毫秒为单位，默认为 5000。任何正整数值都可以接受，但值太小会导致抖动，因为在使用任何消息之前光标会不断重置。
实际上，如果队列是 FIFO 并且队列中只有一个读取器可以接收消息，则无论 RESCANINT 设置为什么，您都将按顺序接收消息。如果要严格保留消息顺序，还有一些其他注意事项，如 Sequential retrieval of messages 中所述。在考虑通道、同步点等时，这些归结为从生产者到消费者只有一条路径的消息。
【讨论】：
请参阅“The order in which messages are retrieved from a queue”一章和以下内容：“Getting a particular message”。
总结：忽略 FIFO 顺序获取消息的唯一方法是通过其消息 ID 或相关 ID 获取特定消息。队列也可以配置为以 FIFO + 优先级顺序交付，但这不是您考虑的选项。最后，如果消息被分组，消息排序会变得复杂，但同样，这不是你的情况。
【讨论】：