Событие получения сообщения ActiveMQ Только Одно сообщение в секунду?

Question

Мы создали инфраструктуру приложений на основе ActiveMQ.

Мы можем отправлять и получать сообщения просто отлично, и по большей части все происходит довольно быстро и нормально.

Однако мы заметили, что если мы отправим пакет сообщений "сразу", скажем, 5000 сообщений, ActiveMQ довольно быстро передаст сообщения стороннему приложению на другом конце, и это приложение также будет обрабатывать их довольно быстро, и что оно также быстро поставит ответы в очередь на отправку брокеру, скажем, менее чем за минуту.

Но по какой-то причине наш VB.NET EXE, который изначально отправил сообщения, похоже, обрабатывает только возвращаемые сообщения, которые он получает, беспорядочно, иногда делая примерно одно в секунду, иногда делая перерывы на час или около того, а затем возвращаясь к одному в секунду.

Origin (VB.NET EXE which we manage) 
    -> Broker  (which we manage)
        -> (3rd party app) 
            -> back to the same broker 
                -> back to the origin app.

Получатель ожидает события MessageListener из кода C #, загруженного с ActiveMQ, возможно, 9 месяцев назад:

Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
     Member of: NMS

Я думаю, что происходит то, что MessageListener предоставляет нам только одно сообщение (NMS.iMessage) для обдумывания, и это то, что мы обрабатываем.

Есть ли какой-нибудь способ сказать "При событии MessageListener, пожалуйста, посмотрите, есть ли другие сообщения в очереди прямо сейчас, и выполните их все"?

Answer 1

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

Когда наш VB.NET Приложение WinForms, использующее ActiveMQ DLL, в конечном итоге выходит из строя, что, как правило, происходит несколько раз в неделю, у нас есть сторожевая программа, которая использует утилиты Winternals pslist и pskill, чтобы уничтожить зомби, а затем запустить новое клиентское соединение.

Когда это происходит, использование jconsole для анализа брокера показывает нам, что сеанс зомби все еще зарегистрирован, как и новый клиент.

Моя теория прямо сейчас заключается в том, что когда AMQ видит оба сеанса, он пытается начать рассылать сообщения обоим сеансам в циклическом стиле.AMQ пытается отправить сообщение зомби, который не отвечает.По истечении определенного промежутка времени (возможно, одной секунды) AMQ сдается и переходит к следующему сеансу в списке, новому свежему клиенту.

В какой-то момент брокер или стек TCP, вероятно, замечает, что зомби не поддерживает свое TCP-соединение активным, и отказывается;затем работа возвращается в нормальное русло.

Итак, возникает вопрос, как написать клиент ActiveMQ, который а) не умирает или б) умирает изящно, завершая сеанс в процессе?

Редактировать:обновление до следующей версии ActiveMQ решило эту проблему.Также у нас было единственное приложение, выполняющее отправку и получение, но оно не было потокобезопасным - так что, если оно получало во время попытки отправки, это приводило к сбоям.Мы переписали его в виде двух консольных приложений, одно из которых отправляло данные, а другое получало их.Больше никаких сбоев.Кроме того, более старая версия ActiveMQ, которую мы использовали в то время, не справлялась с сбоями корректно, обновление до 4.x решило эту проблему.

Answer 2

Я бы предложил сообщить об этом в Форум пользователей наряду с, возможно, воспитанием проблема со службой поддержки поскольку это звучит так, как будто это может быть какая-то проблема с клиентским кодом NMS, и все разработчики NMS находятся в этом списке и могут отреагировать