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

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


vb.net activemq
person Kyle    schedule 23.12.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person Kyle    schedule 09.01.2009

arrow_upward
0
arrow_downward

Я предлагаю сообщить об этом на форум пользователей, а также, возможно, поднять < href="http://activemq.apache.org/camel/support.html" rel="nofollow noreferrer">проблема поддержки, так как это может быть связано с кодом клиента NMS и всеми Разработчики NMS находятся в этом списке и могут ответить

person James Strachan    schedule 31.12.2008