Будет ли коррелированный MQGET очищать другие просроченные сообщения в очереди?
Когда вы делаете "нормальный" MQGET Насколько я понимаю, в очереди MQ сообщения с истекшим сроком действия (те, чье время истекло) не будут получены. Вместо этого они будут выброшены, и будет предпринято следующее сообщение в очереди.
Мой вопрос касается взаимосвязанных операций MQGET. Поскольку они специально ищут сообщение с заданным идентификатором корреляции, обходят ли они обычный механизм, который приводит к удалению сообщений с истекшим сроком?
Другими словами, поскольку они ищут конкретное сообщение, они просто идут прямо к этому сообщению?
Очевидно, что если срок действия этого сообщения истек, оно будет отброшено, мой вопрос касается сообщений в очереди до этого момента.
1 ответ
Сообщение с истекшим сроком никогда не будет возвращено вашему приложению, получаете ли вы его напрямую через MsgId или CorrelId, или если вы получаете его рядом с ним.
Сообщения с истекшим сроком действия удаляются из очереди как внутренней задачей, так и путем передачи MQGET, замечающих их.
Это подробно описано здесь на developerWorks, где говорится:
Чтобы исправить эту ситуацию [сообщения с истекшим сроком хранения остаются в очередях, потому что MQGET не пытается их прочитать] на платформе z/OS, вы можете указать период времени для сообщений, которые должны быть удалены, с помощью атрибута администратора очередей EXPRYINT (интервал истечения). Каждый раз, когда истекает интервал истечения, администратор очередей сканирует очереди, чтобы отменить сообщения с истекшим сроком действия.
Если ваш администратор очередей расположен на распределенной платформе UNIX, в MQ V6 включена задача expirer, которая работает аналогичным образом для распределенных платформ.
У IBM также есть более официальная техническая справка, подробно описывающая поведение и размещенная здесь:
Начиная с WMQ V6.0, была добавлена функциональность для автоматического удаления сообщений с истекшим сроком.
Когда срок действия сообщения истекает, оно будет отброшено, когда: MQGET, соответствующий сообщению, будет выпущено, или оно будет внутренне удалено задачей expirer администратора очередей.
По умолчанию внутренняя задача expirer выполняется каждые 300 секунд (5 минут). Если вы хотите изменить частоту выполнения этой задачи, вы можете использовать параметр "ExpiryInterval". Это значение настраивается в секундах с диапазоном от 1 до 1 000 000 секунд. Если вы установите значение "0", вы отключите задачу.
В z/OS ExpiryInterval является атрибутом администратора очередей. На распределенных платформах ExpiryInterval можно добавить в раздел "TuningParameters" в файле qm.ini администратора очередей.