Сообщения серии MQ читаются более одного раза - PullRequest
Новая
       6

Сообщения серии MQ читаются более одного раза

3 голосов
/ 16 февраля 2011

У меня проблема с тем, что сообщение иногда читается из Q более одного раза. Я использую .NET-оболочку для MQSeries (amqmdnet.dll) и читаю сообщения, используя Win Service. 

Here's how I do it with VB.NET:

'QManager
 Dim properties As Hashtable = New Hashtable(4)

        properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT)
        properties.Add(MQC.CHANNEL_PROPERTY, channelName)
        properties.Add(MQC.HOST_NAME_PROPERTY, iPAddress)
        properties.Add(MQC.PORT_PROPERTY, port)

        QManager = New MQQueueManager(queueManagerName, _
                                              properties)


'Q itself
getMessageOptions.Options = _
            MQC.MQGMO_FAIL_IF_QUIESCING Or _
            MQC.MQGMO_WAIT Or _
            MQC.MQGMO_SYNCPOINT

getMessageOptions.WaitInterval = 1000 ' read from config

Dim locker As New Object

System.Threading.Monitor.Enter(locker)

Q.Get(message, getMessageOptions)

QManager.Commit()

System.Threading.Monitor.Exit(locker)

Я слышал, что Q.Get (message, getMessageOptions) делает сообщение недоступным для других читателей, QManager.Commit в свою очередь просто удаляет сообщение из Q (по аналогии с .NET Peek & Dequeue). Это само по себе должно устранить необходимость в мониторе.

В моем Win Service несколько потоков читают Q, и мы подозреваем, что из-за малого интервала опроса (100 мс и менее), оболочка не получает достаточно времени для обновления флага «Чтение» сообщения, поэтому его забирают более одного раза, перекрывая темы. Исторически одно и то же сообщение читалось до четырех раз.

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

Спасибо.

1 Ответ

5 голосов
/ 17 февраля 2011

Давайте рассмотрим ряд пунктов из поста и последующих комментариев:

  1. Выполнение GET в WMQ действительно делает сообщение недоступным для других читателей. GET вне syncpoint постоянно отменяет сообщение немедленно, тогда как GET под syncpoint делает сообщение недоступным для других читателей, пока не произойдет BACKOUT. Однако операция BROWSE не обеспечивает такой защиты.
  2. Диспетчер очереди обеспечивает доступ к сообщениям. Прямое манипулирование MQ-приложением с очередью или внутренними сообщениями отсутствует, и, следовательно, у .Net-оболочки нет возможности манипулировать «флагом чтения».
  3. Интервал ожидания - это как долго ожидающий GET блокирует программу, если в очереди нет доступных сообщений и со значением 1000 этот интервал равен одной секунде. Если в очереди много сообщений, и программа сразу же зацикливается, эффективный интервал опроса, тем не менее, длится программе, чтобы обработать сообщение. Интервал ожидания не влияет на пропуск очереди сообщений из глубокой очереди, поскольку администратору очередей не приходится ждать прибытия сообщения.
  4. WMQ предлагает несколько различных уровней надежности. Они контролируются такими вещами, как постоянство сообщений, режим подтверждения и транзакционность. Например, непостоянное сообщение, полученное вне единицы работы, обеспечивает надежность не более одного раза.

Что касается многопоточности и синхронизации, то WebSphere MQ: Использование .Net manual содержит следующее: :

Реализация WebSphere® MQ .NET гарантирует, что для данного соединение (объект MQQueueManager экземпляр), все доступ к цели Администратор очередей WebSphere MQ синхронизированы. Поведение по умолчанию что нить, которая хочет выдать звонок администратору очередей заблокирован пока все остальные звонки в процессе это соединение установлено. если ты требуется одновременный доступ к один и тот же администратор очередей из нескольких темы в вашей программе, создайте новый объект MQQueueManager для каждого поток, который требует одновременного доступ. (Это эквивалентно выдаче отдельный вызов MQCONN для каждого нить.)

Если параметры подключения по умолчанию переопределено MQC.MQCNO_HANDLE_SHARE_NONE или MQC.MQCNO_SHARE_NO_BLOCK, то администратора очередей больше нет синхронизируется.

Так что синхронизация для вас сделана, но точное поведение зависит от того, имеет ли каждый поток свое собственное соединение. Это потому, что транзакции ограничены подключением. Если одно соединение обслуживает множество потоков, а один из потоков вызывает COMMIT, то все потоки в этом соединении находятся в одной единице работы и все COMMIT одновременно.

Есть несколько возможностей, которые могут привести к дублированию сообщений, кроме просмотра их. Все это варианты сообщений, подлежащих возврату. Отказы не всегда могут быть под контролем программы. Когда многие транзакции синхронизируются одновременно, в игру вступают несколько пределов настройки, включая MAXUMSGS, первичные и вторичные экстенты файла журнала и некоторые другие. Если какой-либо из этих пределов будет превышен, QMgr отменит самую старую непогашенную единицу работы, чтобы освободить место для следующей. Другая причина, по которой происходит возврат, - это если клиентское соединение прерывается. В этом случае любой GETS в syncpoint откатывается и сообщения снова становятся доступными.

Один из способов определить, происходит ли это, - проверить количество возвратов сообщений во время их чтения. Надежное приложение для обмена сообщениями будет регулярно проверять это значение как часть сообщений о подозрительных сообщениях и запрашивать (или удалять и регистрировать) сообщения, когда количество возвратов превышает некоторый произвольный порог. Это предотвращает нечитаемое сообщение от постоянной блокировки потока. При обнаружении повторяющихся сообщений может быть полезно регистрировать любые сообщения, в которых количество возвратов превышает ноль, а не просто повторно запрашивать те, которые превышают пороговое значение.

Другой способ точно определить, что происходит, - использовать средства трассировки WMQ или SupportPac MA0W . Любой из них покажет, какие именно вызовы API выполняются, какими приложениями и потоками и с какими параметрами. Если ваша трассировка показывает, что повторяющиеся сообщения доставляются на вызовы GET без просмотра без BACKOUT, то это дефект, для которого вы можете запросить исправление.

Если вы используете старый код .Net, существует небольшая вероятность того, что проблема является исправленной ошибкой. Я не видел каких-либо дефектов в списках исправлений, которые могли бы привести к дублированию сообщений, но если ваш .Net-клиент не в последней версии 7, вы все равно должны рассмотреть возможность обновления в ближайшее время. Классы v7 гораздо более функциональны и фактически полностью интегрированы в WMQ и поддерживаются. Существует также небольшая проблема, связанная с прекращением поддержки WMQ v6 с сентября 2011 года. Вы можете получить последний клиент WMQ в SupportPac MQC7 . Если вы уже установили клиент v7 и нуждаетесь в обновлении до v7.0.1.4, вы можете установить последний клиент поверх более старого v7 или применить последний пакет Fix Pack (FP 7.0.1.4 на момент написания этой статьи) из Страница рекомендуемых исправлений . Пакет исправлений обновляет как клиента, так и сервера.

...