Задержка выполнения потребителем ActiveMQ

Я вижу проблему, когда очередь не копируется, однако время для фактического выполнения пользователем сообщения JMS составляет от 100 до 200 секунд с момента создания (согласно измерениям с помощью JMSTimestamp-CurrentTime).

Поток в очереди был довольно низким, менее 30 сообщений в минуту. Мне удалось решить проблему, перезапустив ActiveMQ, после чего сообщения запускались менее чем через 1 мс с момента их создания.

Я использую ActiveMQ 5.4.1, и нормальное общее время выполнения работы, выполняемой в MDB, составляет менее 2 мс. Во время задержки сообщений об ошибках в журнале ActiveMQ не было, ЦП был низким и имел много памяти.

Похоже, что потребитель вытаскивает сообщение из очереди, но почему-то сидит на нем.

Есть ли какие-то проблемы с конфигурацией, которые могут вызывать эту проблему?

Редактировать:

Первая строка моего MDB выглядит следующим образом:

 /* Check the time since this message was created versus processed */
        try {
            long secondsToProcess = TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis() - aMessage.getJMSTimestamp());
            if (secondsToProcess > 5) {
                log.error("JMS Consumer Start Delay: " + secondsToProcess + " s" + " JMS Message took more then 5 seconds to be processed");
            } else {
                log.debug("JMS Consumer Start Delay: " + secondsToProcess + " s");
            }
        } catch (Exception e) {
            log.error(e);
        }

person Jeremy    schedule 19.11.2010    source источник
comment
Вы пытались поместить оператор журнала прямо в начало MDB, чтобы убедиться, что он действительно его получает? Это похоже на какую-то странную ошибку транзакции.   -  person javamonkey79    schedule 19.11.2010
comment
Да, см. Обновленный вопрос   -  person Jeremy    schedule 19.11.2010


Ответы (2)


Насколько вы уверены, что потребитель немедленно удаляет сообщение из очереди? ActiveMQ предоставляет свойства JMSActiveMQBrokerInTime и JMSActiveMQBrokerOutTime, которые вы можете использовать для подтверждения (см. свойства сообщения ActiveMQ).

person SimonJ    schedule 19.11.2010
comment
SimonJ, общее время в брокере почти точно равно System.currentTimeMillis () - aMessage.getJMSTimestamp (). Это говорит мне о том, что брокер не спешит их вводить / выводить. - person Jeremy; 02.12.2010

Как оказалось, ActiveMQ вел себя нормально, мои рабочие работали слишком долго, поэтому выполняли резервное копирование очереди. Код в моем вопросе позволил мне это увидеть.

person Jeremy    schedule 09.01.2012