Spring JMS并发和JMSXGroupID [英] Spring JMS Concurrency and JMSXGroupID

查看:440
本文介绍了Spring JMS并发和JMSXGroupID的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在TomEE容器内的Web应用程序中使用Spring JMS,我想使用JMSXGroupID将消息分组在一起.我使用以下Spring JMS侦听器容器配置.

I'm using Spring JMS in my web application inside a TomEE container and I wanted to use JMSXGroupIDs to group my messages together. I use the following Spring JMS Listener Container configuration.

<jms:listener-container container-type="default" connection-factory="jmsFactory" cache="none" acknowledge="auto" transaction-manager="transactionManager" concurrency="1-5" >
    <jms:listener id="files-queue-listener" selector="mimetype ='application/xml'" destination="filesQueue" ref="filesQueueListener"/>
</jms:listener-container>

为了进行快速测试,我发送了1000条消息,这些消息由相同的JMSXGroupID分组在一起.我使用VisualVM查看了线程,并希望在整个测试过程中仅看到一个活动的侦听器容器.发生的事情是,工作被划分为5个消息侦听器容器.我检查了ActiveMQ Web控制台,就代理而言,所有消息都发送给了同一使用者.有什么理由可以在不同的消息侦听器容器线程上处理消息?

For a quick test, I sent 1000 messages grouped together by the same JMSXGroupID. I looked at the threads using VisualVM and I expected to see only one listener container active during the whole test. What happened is that the work is divided between the 5 message listener containers. I checked the ActiveMQ Web Console and as far as the broker is concerned, the messages were all sent to the same consumer. Is there any reason why the messages would be processed on different message listener container threads?

推荐答案

首先,使用一些术语-一个容器具有5个使用者线程(从ActiveMQ的角度来看,这是5个使用者).

First, some terminology - there is one container with 5 consumer threads (5 consumers from ActiveMQ's perspective).

我刚刚对5个固定消费者进行了测试,并且效果达到了预期.

I just ran a test with 5 fixed consumers and it worked as expected.

当我与变量使用者一起运行时,当容器增加了使用者计数时,我确实看到具有相同组ID的消息将发送给新"使用者.然后,通过向相同(新)使用者发送的邮件,该邮件变得稳定了.

When I ran with variable consumers I did see messages with the same group id going to a "new" consumer when the container increased the consumer count; it then stabilized with the messages going to the same (new) consumer.

由于ActiveMQ负责分发,因此在创建新使用者时,它必须是其算法中的一部分.我认为这与Spring无关.

Since ActiveMQ is responsible for the distribution, it must be something in its algorithm when new consumers are created; I don't think it's anything to do with Spring.

更改为固定数量的消费者可能是可行的解决方法.

Changing to a fixed number of consumers might be a viable workaround.

编辑

在这里使用可变使用者可能不是一个好主意,因为当容器检测到速度变慢时,它将关闭使用者-这将迫使ActiveMQ开始对任何相关组使用不同的使用者.

Using variable consumers here is probably not a good idea anyway because when the container detects a slow down it will shutdown consumers - which will force ActiveMQ to start using a different consumer for any associated groups.

这篇关于Spring JMS并发和JMSXGroupID的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆