2012-01-18 3 views
1

У меня проблема с запросом на подсчет сообщений из очереди удаленного msmq.Чтение количества сообщений MSMQ с ruby ​​

Это мой код:

def get_message_count 
    mq_management = WIN32OLE.new('MSMQ.MSMQManagement') 
    mq_management.Init('xxx.yyy.zz.aa', nil,'direct=tcp:xxx.yyy.zz.aa\private$\inbox') 
    message_count = mq_management.MessageCount 
end 

xxx.yyy.zz.aa является IP-адрес удаленного компьютера.

Этот метод действительно работает как шарм, НО:

  1. , если очередь пуста, то я получаю эту ошибку после определенного промежутка времени:

    `method_missing ': Init (WIN32OLERuntimeError) Код ошибки OLE: C00E0004 в MSMQManagement Очередь не открыта или может отсутствовать. Код ошибки HRESULT: 0x80020009 Исключение.

  2. Если в очереди есть предметы, то этот метод работает так, как он предполагал.

Я нашел эту статью: How do I create an MSMQ outgoing queue? , который говорит:

MSMQ поддерживает очередь живой (даже если он пуст) в течение нескольких минут только в случае, если вы собираетесь отправить еще одно сообщение. Это избавляет менеджера очереди от попыток сделать сетевое подключение еще раз. Эта задержка очистки контролируется значением реестра CleanupInterval - 5 минут для клиентов и 2 минуты для серверов.

В настоящее время мы не можем изменить настройки реестра. Другой вариант, вероятно, заключается в попытке получить сообщение через WMI, но я не уверен, как вы это делаете в ruby ​​(будучи разработчиком .NET).

Возможно, есть возможность «проснуться» в очереди?

Буду признателен за любую помощь! Спасибо

ответ

1

Для эффективности, MSMQ не поддерживает данные о производительности на очереди, которые:

  1. Empty, и
  2. Закрытое

Вы могли бы, например, иметь машину с тысячами пустых очередей, которые блокировали бы ресурсы памяти, если бы такие данные активно поддерживались. Эффективно, пустые очереди не существуют, как вещи для анализа, пока они не были открыты приложением.

Мое сообщение в блоге об исходящих очередях не имеет ничего общего с этой ситуацией, поскольку вы запрашиваете информацию о частной очереди.

Приветствия Джон Breakwell

+1

Привет Джон, спасибо за Ваш ответ. Эта проблема с очередями сообщений, потребляющими много ресурсов, теперь хорошо понятна мне. Однако эта часть: «Эффективно, пустые очереди не существуют, как вещи для анализа, пока они не будут открыты приложением». представляет собой небольшую проблему. Запрос «неактивной» очереди сообщений приводит к тому же исключению, что и при недоступности сервера. поэтому трудно сказать, в чем причина. Если пустые очереди «фактически не существуют», тогда не должно быть возможности анализировать счетчики производительности для этой очереди. Неужели это невозможно? – Helikaon

+0

Простой тест: Загрузите монитор производительности и попробуйте добавить экземпляр объекта «Очередь MSMQ \ Сообщения в очереди». Список очередей, которые вы можете выбрать, НЕ будет включать пустые/неактивные очереди. –

+0

Обходным путем было сообщение в каждой очереди, которое приложение-получатель никогда не читает. Это сообщение «keepalive» обеспечивает отображение очереди для мониторинга производительности. Очевидно, что это не работает для приложений, которые просто автоматически получают сообщения с верхней части очереди. –

Смежные вопросы