Событие получения сообщения ActiveMQ только одно сообщение в секунду? - PullRequest
Новая
       23

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

0 голосов
/ 23 декабря 2008

Мы создали инфраструктуру приложений на основе 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, пожалуйста, посмотрите, есть ли другие сообщения в очереди прямо сейчас и сделайте их все"?

Ответы [ 2 ]

1 голос
/ 09 января 2009

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

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

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

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

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

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

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

0 голосов
/ 31 декабря 2008

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

...