选择性出列的消息是否保留在 FIFO 顺序 (MQ) 中？
使用 JMS 和WebSphere MQ，如果我使用消息选择器选择性地出队，并且有多个具有相同选择标准的消息，我是否保证将第一个匹配的消息出队？
例如，给定一个包含消息的队列
{color: Pink, name: alice}{color: blue, name: bob}{color: red, name: charlie}{color: blue, name: doug}
如果我使用选择器 color='blue' 出列，我是否保证使 {color:蓝色，姓名：鲍勃}？或者我是否有机会得到 {color: blue, name: doug} ，即使它更深入队列深度？
Using JMS & WebSphere MQ, if I use a message selector to selectively dequeue, and there are several messages with the same selection criteria, am I guaranteed to dequeue the first message that matches?
e.g. given a queue with messages
{color: pink, name: alice}{color: blue, name: bob}{color: red, name: charlie}{color: blue, name: doug}
if I dequeue with the selector color='blue', am I guaranteed to dequeue {color: blue, name: bob}? Or is there a chance I could get {color: blue, name: doug} instead, even though it is further into the queue depth?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请参阅 RESCANINT 不同 WMQ 连接工厂实现的属性。从手册中：
这个想法是，在具有优先级传递的非常繁忙的队列中，一些较高优先级的消息可能在队列中出现得比选择器的当前位置更高。理论上，优先级较高的消息应该首先被消费，但消费者不会看到它，除非它从队列的头部寻找。当光标到达队列末尾或到达 RESCANINT 时，光标将重置到队列的头部。 RESCANINT 的设置允许调整您希望选择器查找这些更高优先级消息的响应速度。
RESCANINT 并不特定于 FIFO 传送。另一种可能发生这种情况的情况是，如果多个线程具有重叠的选择标准。在这种情况下，一个线程可以锁定一条消息，然后释放它。尽管该消息可能适合第二个线程，但如果该线程已经通过了队列中的该位置，则需要到达队列末尾或经过 RESCANINT 才能重新启动游标以查找该消息。
重新扫描间隔以毫秒为单位，默认为 5000。接受任何正整数值，但太低的值会导致抖动，因为在使用任何消息之前游标会不断重置。
实际上，如果队列是 FIFO，并且队列上只有一个符合条件的读取器，则无论 RESCANINT 设置为多少，您都将按顺序接收消息。如果要严格保留消息顺序，则需要一些额外的注意事项，如 消息的顺序检索。当考虑通道、同步点等时，这些归结为消息从生产者到消费者只有一条路径。
Please refer to the RESCANINT property of the different WMQ Connection Factory implementations. From the manual:
The idea is that in a very busy queue with priority delivery, some messages of a higher priority may appear higher in the queue then the current position of the selector. Theoretically a higher priority message should be consumed first but the consumer won't see it unless it seeks from the head of the queue. The cursor is reset to the head of the queue either when it gets to the end or when RESCANINT is reached. The setting of RESCANINT allows for tuning of how responsive you want the selector to be in finding these higher priority messages.
RESCANINT isn't specific to FIFO delivery. The other case in which this can happen is if there are multiple threads with overlapping selection criteria. In this case one thread can hold a message under lock and then release it. Although the message may be eligible for the second thread, if that thread has already passed that position in the queue then it takes hitting the end of the queue or RESCANINT elapsing to restart the cursor to find the message.
Rescan interval is in milliseconds and defaults to 5000. Any positive integer value is accepted, although too low a value will cause thrashing as the cursor is continually reset before any messages can be consumed.
As a practical matter, you will receive the messages in order if the queue is FIFO and you have only one reader on the queue for which the messages are eligible, regardless of what RESCANINT is set to. If message order is to be strictly preserved, there are some additional considerations as described in Sequential retrieval of messages. These boil down to messages having only one path from producer to consumer when considering channels, syncpoints, etc.
请参阅“章节从队列中检索消息的顺序”和以下内容：“获取特定消息”。
总结：忽略 FIFO 顺序获取消息的唯一方法是通过消息 id 或相关 id 获取特定消息。队列也可以配置为按 FIFO + 优先级顺序传送，但这不是您考虑的选项。最后，如果消息被分组，消息排序就会变得复杂，但同样，这不是你的情况。
See the chapter "The order in which messages are retrieved from a queue" and the following: "Getting a particular message".
Summing up: the only way to get a message ignoring FIFO order is to fetch a specific message by its message id or correlation id. A queue may also be configured to deliver in FIFO + priority order, but that's not an option you consider. Finally, message ordering complicates if messages are grouped, but again, it's not your case.