ActiveMQ + Spring + DefaultMessageListenerContainer — крайне низкая производительность

У меня есть установка DefaultMessageListenerContainer со следующей конфигурацией:

threadServiceListenerContainer(org.springframework.jms.listener.DefaultMessageListenerContainer) {
        maxConcurrentConsumers = 10
        concurrentConsumers = 1
        destinationName = 'releaseThread'
        pubSubDomain = false
        connectionFactory = ref("connectionFactory")
        messageListener = ref('threadServiceMessageListener')
    }

В брокере хранится 3000 незавершенных сообщений. Скорость потребления вроде бы 2/сек. Я подключил JProfiler к узлу Java, но кажется, что 10 потоков прослушивания/потребителей в худшем случае простаивают или в лучшем случае работают по одному за раз.

Время обработки потребителя не регистрируется в JProfiler. Потребитель просто добавляет ценность memcached, и memcached работает нормально.

Кажется, мой потребитель просто... сидит...

Есть предположения? Я перезагрузил брокера, никакой разницы в производительности. Я перезагрузил узел, никакой разницы в производительности.

Я внедряю Map в брокера.

Вот мой компонент connectionfactory:

connectionFactory(org.springframework.jms.connection.CachingConnectionFactory, ref("amqConnectionFactory")) {
        exceptionListener = {com.zipwhip.jms.JmsExceptionListener jmsExceptionListener -> }
        sessionCacheSize = 100
    }
    amqConnectionFactory(org.apache.activemq.ActiveMQConnectionFactory) {
        brokerURL = 'tcp://localhost:61616'
    }

java activemq
person Michael Smyers    schedule 27.04.2011    source источник
comment
какую версию AMQ вы используете? похоже, что эта проблема была исправлена ​​в версии 5.4, issues.apache.org/jira/browse /AMQ-2754   -  person Ben ODay    schedule 01.03.2012

Ответы (1)


arrow_upward
0
arrow_downward

Я бы порекомендовал попробовать пару вещей: установить для управления потоком производителя значение false и изменить политику отправки. Попробуйте изменить один или оба, чтобы увидеть, поможет ли это. У нас были проблемы с производительностью ActiveMQ (работа встраивается в OpenEJB), но, наконец, все заработало гладко.

Чтобы изменить их с помощью activemq.xml, используйте это:

<destinationPolicy>
            <policyMap>
                <policyEntries>
                    <policyEntry queue=">" producerFlowControl="false" enableAudit="false" >
                        <dispatchPolicy>
                            <roundRobinDispatchPolicy />
                        </dispatchPolicy>
                    </policyEntry>
                </policyEntries>
            </policyMap>
</destinationPolicy>

Кроме того, мы обновили ActiveMQ 4.x до 5.3.1 и перешли с сохраняемости JDBC/журнала на сохраняемость KahaDB.

person topchef    schedule 27.04.2011
comment
Я на самом деле обеспокоен тем, что, возможно, пытаюсь направить слишком много трафика через 1 соединение. Вы, ребята, используете CachingConnectionFactory? У вас есть несколько базовых соединений? - person Michael Smyers; 27.04.2011
comment
у нас есть один производитель и несколько потребителей (обычно). Мы используем J2EE, а не Spring. Одна вещь, которую мы делаем при отправке в activeMQ, — это установка для useAsyncSend значения true. Фабрика соединений с очередью — это фабрика соединений по умолчанию, которую мы получаем от ActiveMQ (через openejb). - person topchef; 27.04.2011