使用和不使用选择器发送到队列都会创建大队列

发布于 2025-01-20 15:22:30 字数 527 浏览 0 评论 0原文

我的系统中有 2 个消费者,它们从同一目的地消费,但有些消息具有特定的选择器,有些则没有。 结果,我看到很多消息被困在选择器消费者中(它们与选择器不匹配),

类似这样:

consumer1: myMessageType = 'Funny'
consumer2: myMessageType = 'Sad'
consumer3: no selector defined

Message 1 : myMessageType = 'Funny'
Message 2 : myMessageType = 'Funny'
Message 3 : myMessageType = 'Sad'
Message 4 : myMessageType = 'Sad'
Message 5 : myMessageType = 'Weird'
Message 6 : myMessageType = 'Weird'

当我查看队列(hawtio 控制台)时,我看到消费者 1 和 2 有一个队列中有很多消息,并且由于消息中缺少选择器而无法使用它们 这是为什么?我是否滥用 amq 系统?

I have 2 consumers in my system, that consume from same destination, but some of the messages have specific selector, and some of them not.
as a result, i see that a lot of messages are stuck in the selector consumer(they are not matching the selector)

something like that:

consumer1: myMessageType = 'Funny'
consumer2: myMessageType = 'Sad'
consumer3: no selector defined

Message 1 : myMessageType = 'Funny'
Message 2 : myMessageType = 'Funny'
Message 3 : myMessageType = 'Sad'
Message 4 : myMessageType = 'Sad'
Message 5 : myMessageType = 'Weird'
Message 6 : myMessageType = 'Weird'

and when i look at the queue(hawtio console), i see that consumer 1 and 2 have a lot of messages in queue, and they cannot consume them because lack of selector in the messages
why is that? am i abusing the amq system?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

茶底世界 2025-01-27 15:22:30

队列只能向 maxPageSize 内的消费者提供消息。这样做是出于性能原因——避免扫描整个数据存储中的消息。如果消费者缺乏消息,则意味着您的消费者选择器覆盖范围存在差距。

您需要:

  1. 添加一个带有选择器的消费者,该选择器捕获所有“其余”消息
  2. 使用过滤的复合目标转移到服务器端消息过滤
  3. 添加基于内容的路由器(即 Camel、Mule 等)以将消息分类到消费者的单独队列,因此他们不需要选择器。

有一个很好的例子表明,选项 #2 和 #3 是比尝试使用 #1 解决它更干净的架构,因为它将有关选择器的所有信息放在一个地方,而不是分散在不同的消费者配置中。

Queues can only provide messages to consumers within the maxPageSize. This is done for performance reasons-- to avoid scanning the entire data store for messages. If consumers are starved of messages, it means you have a gap in your consumer selector coverage.

You either need to:

  1. Add a consumer with a selector that catches all the 'rest' of messages
  2. Move to server-side filtering of messages using filtered composite destinations
  3. Add a content-based router (ie Camel, Mule, etc) to sort messages into individual queues for consumers so they do not need selectors.

There is a pretty good case to be made that options #2 and #3 are cleaner architecture than trying to solve it with #1, since it puts all the information about the selectors in one place, vs scattered in different consumer configurations.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文