需要选择器的 JMS 队列
我想实现一个 JMS 队列来确保每条消息仅传递给一个消费者。会有很多不同类型的消费者在监听队列。消息应该设置属性来标识所需的工作类型，并且消费者选择器使用这些属性来确保他们只收到他们可以处理的发送的工作。
我的问题是，当消费者作为消费者注册到队列时，如何确保他们实现选择器以避免以下情况。
如果我有 3 种消息类型（A、B 和 C）和 3 个消费者（a、b 和 c），每个消费者仅消耗 1 种消息类型，如下所示： a->A b->B c->C 那么所有A 类型的消息将被发送到 1，B 类型的所有消息将被发送到 2 等等。
我想防止有人注册一个没有选择器的新消费者 (d)，因为这个消费者意味着 A、B 类型的消息,C 现在要么去他们的预期消费者或可能的消费者 d．
或者，我希望队列优先考虑有选择器的消费者，而不是没有选择器的消费者。
诗。可能的消费者和消息类型的列表是动态的，不受我的控制，这就是为什么我没有针对每种消息类型的队列。
I want to implement a JMS Queue to ensure that each message is only delivered to one consumer. There will be many different types of consumers on listening to the queue. Messages should have properties set which identify the type of work required and these are used by the consumers selector to ensure that they only get sent work which they can handle.
My question is how can I make sure that when a consumer registers with the Queue as a consumer that they implement a selector to avoid the following scenario.
If I have 3 message types (A, B and C) and 3 consumers (a, b and c) which each consume only 1 message type as follows: a->A b->B c->C then all messages of type A will be sent to 1, all messages of type B will be sent to 2 etc.
I want to prevent someone registering a new consumer (d) which has no selector because this consumer would mean that messages of type A,B,C would now either go to their intended consumer or possibly consumer d.
Alternatively I would like the queue to give preference to consumers which have a selector that matches over a consumer with no selector.
Ps. The list of possible consumers and message types is dynamic and not in my control which I why I don't have a queue for each message type.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您无法在 JMS API 实现级别上实现它。我认为最好的选择是对代理中的队列施加安全限制，例如应用程序必须提供的用户/密码才能读取队列，并且只有您的应用程序知道。请参阅您的 JMS 提供程序文档了解如何执行此操作，这是任何严肃的 JMS 提供程序的标准功能。
我有一种感觉，你不想要它是出于安全原因，而是为了稳定、你自己的内心平静，或者“以防万一”。您可能必须说服公司中管理队列的人这是合理的。
You cannot achieve it on the JMS API implementation level. I think your best bet is to impose security restrictions on the queue in the broker, like a user/password that your application has to supply to read the queue, and that only your application will know. Consult your JMS provider docs how to do it, it is a standard feature for any serious JMS provider.
I have a feeling you don't want it for security reasons, but for stability, your own peace of mind, or "just in case". You'll probably have to convince whoever-administers-the-queues in your company this is justified.