英文:
Large delays in message consumption of messages in ActiveMQ
问题
我们拥有一个经纪人网络，由三个位于不同服务器上的经纪人组成。
网络连接器的配置如下所示：
<networkConnectors>
<networkConnector uri="static:(ssl://broker2:61616,ssl://broker3:61616)" networkTTL="5"/>
</networkConnectors>
整体设置如下图所示。
实际情况中，我们有时会看到特定客户端的消息消费存在较大延迟。在这种情况下，消息在最终被消耗之前会多次转发到其他经纪人。到目前为止，我们还无法找出可能导致这种情况的原因。
消费者并不是非常繁忙。它们是使用 Spring JMS 库实现的。每个经纪人的最小消费者数量为3个，但这可以根据需要自动进行扩展。
我们怀疑只影响特定客户端的原因可能与我们使用的 JMSGroupId 有关，以便对处理消息的顺序进行一些排序。然而，我们没有确凿的证据证明这一点。这仍然不能解释为什么会发生这种情况。
我们还考虑向网络连接器添加以下参数，因为我们认为这可能会改善行为：
dynamicOnly="true"
decreaseNetworkConsumerPriority="true"
suppressDuplicateQueueSubscriptions="true"
然而，这也让人感到不安，因为我们觉得我们并不完全了解当前发生的情况，因此无法确切地确定这些设置对行为的影响。
英文:
We have a network of brokers consisting of three brokers on different servers.
The network connectors are configured as follows:
<networkConnectors>
<networkConnector uri="static:(ssl://broker2:61616,ssl://broker3:61616)" networkTTL="5"/>
</networkConnectors>
The overall setup looks like what is shown in the image below.
In practice we sometimes see large delays for the message consumption of a specific client. In that case, messages are forwarded multiple times to other brokers before finally being consumed. Until now, we have been unable to find out what might be the cause of this.
The consumers are not very busy. They are implemented using the Spring JMS library. The minimum number of consumers is 3 per broker, but this can automatically scale depending on the need.
We suspect that the reason that only a specific client is impacted, might have something to do with the fact that we use the JMSGroupId to get some ordering in how the messages are handled. However, we have no sure proof of this. And it still doesn't explain why it happens at all.
We are also considering to add the following parameters to the network connector as we think this might improve the behavior:
dynamicOnly="true"
decreaseNetworkConsumerPriority="true"
suppressDuplicateQueueSubscriptions="true"
However, it is also scary to do as we feel we do not fully understand what is happening right now and so cannot really be sure of the effect these settings will have on the behavior.
答案1
得分: 0
我们怀疑只有特定的客户端受到影响的原因，可能与我们使用的 JMSGroupId 有关，以便在处理消息的顺序方面获得一些排序。
明白。
如果你确保了串行消息处理，那么扩展消费者就没有意义。摆脱这种行为的最佳方法是设置一个专用的 JMS 队列，每个组只有一个消费者，否则在队列中的多个后续消息属于同一组时，会出现消费者争用的情况。
详情请见 https://stackoverflow.com/q/33500395/2087640。
英文:
> We suspect that the reason that only a specific client is impacted,
> might have something to do with the fact that we use the JMSGroupId to
> get some ordering in how the messages are handled.
Bingo.
Scaling consumer is useless if your ensure serial message processing. The best way to get rid of this behavior is to set up a dedicated JMS queue with a single consumer per group, otherwise you will experiment consumer contention when multiple following messages in the queue belong to the same group.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论