JMS - 消息选择器如何与多个队列和主题消费者一起工作？
假设您有一个 JMS 队列，并且多个使用者正在监视队列中的消息。您希望其中一个使用者获得所有特定类型的消息，因此您决定使用 消息选择器。
例如，您可以在 JMS 消息标头中定义一个名为 targetConsumer 的属性。您应用于名为 A 的使用者的消息选择器类似于 WHERE targetConsumer = 'CONSUMER_A'。
很明显，消费者 A 现在将只获取具有属性集的消息，如示例中所示。那么其他消费者会意识到这一点吗？ IOW，如果另一个不受消息选择器约束的消费者在消费者 A 之前查看队列，它会抓取 CONSUMER_A 消息吗？我是否需要应用消息选择器，例如 WHERE targetConsumer <>向其他人发送“CONSUMER_A”？
我现在正在进行 RTFMing 并收集经验数据，但希望有人能够立即了解。
Say you have a JMS queue, and multiple consumers are watching the queue for messages. You want one of the consumers to get all of a particular type of message, so you decide to employ message selectors.
For example, you define a property to go in your JMS message header named, targetConsumer. Your message selector, which you apply to the consumer known as, A, is something like WHERE targetConsumer = 'CONSUMER_A'.
It's clear that consumer A will now just grab messages with the property set like it is in in the example. Will the other consumers have awareness of that, though? IOW, will another consumer, unconstrained by a message selector, grab the CONSUMER_A messages, if it looks at the queue before Consumer A? Do I need to apply message selectors like, WHERE targetConsumer <> 'CONSUMER_A' to the others?
I am RTFMing and gathering empirical data now, but was hoping someone might know off the top of their head.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当多个消费者使用同一个队列时，需要在这些消费者之间正确配置消息选择器，以便在确定预期消费者时不会发生冲突。
对于消息驱动 bean（JMS 消息的使用者），可以在 ejb-jar.xml 文件中指定选择器，从而允许在部署时完成配置（而不是指定开发期间的消息选择器）。
编辑：在现实生活中，当不同的消费者负责处理写入同一队列的包含相同标头（通常由同一生产者生成）的消息时，这是有意义的。例如，当生产者无法将 JMS 消息写入两个单独的买卖队列时，可以在交易应用程序中使用消息选择器来区分买卖订单。
When multiple consumers use the same queue, message selectors need to configured correctly across these consumers so that there is no conflict in determining the intended consumer.
In the case of message-driven-beans (a consumer of JMS messages), the selector can be specified in the ejb-jar.xml file thereby allowing for the configuration to be done at deployment time (instead of the opposing view of specifying the message selector during development).
Edit: In real life, this would make sense when different consumers are responsible for processing messages containing the same headers (often generated by the same producer) written onto the same queue. For instance, message selectors could be used in a trading application, to differentiate between buy and sell orders, when the producer is incapable of writing the JMS messages onto two separate buy and sell queues.
是的，不使用任何消息选择器的另一个消费者将获得发送给消费者 A 的消息（或者队列顶部的任何消息）。因此，在共享队列时，消费者应用程序必须遵守纪律并仅选择那些适合它们的消息。
Yes, another consumer which is not using any message selector will get message intended for consumer A (or for that matter any message on top of the queue). Hence when sharing a queue, consumer applications must be disciplined and pick only those messages intended for them.
如果选择器匹配，队列中的“第一个”JMS 消息使用者将拾取该消息。 “第一”的意思是实现细节（可以是循环法，基于优先级或网络紧密程度）。因此，在队列上使用选择器时，您需要确保这些选择器“不重叠”。
更正式地说：不得存在与同一队列上的 2 个选择器匹配的消息
这是队列与主题相比的另一个缺点 - 在实践中，您应该始终首先考虑使用主题。通过一个主题，每个匹配的消费者都会收到消息。
The 'first' JMS message consumer from a queue will pick up the message if the selector matches. What 'first' means is an implementation detail (could be round-robin, based on priority or network closeness). So when using selectors on queues you need to make sure that these selectors are 'non overlapping'.
More formally: no message must exist that matches 2 selectors on the same queue
This is yet another disadvantage of queues versus topics - in practice you should always consider using topics first. With a topic each matching consumer receives the message.