Будет ли MQSC определять команду очереди для удаления или повреждения сообщений? - PullRequest
Новая
       42

Будет ли MQSC определять команду очереди для удаления или повреждения сообщений?

2 голосов
/ 06 декабря 2011

В WebSphere MQ 6 я хочу создать сценарий создания новых очередей.Однако очереди могут уже существовать, и мне нужно, чтобы скрипт был идемпотентным.

Я могу создавать очереди, используя команды , задокументированные здесь .Например: 

DEFINE QREMOTE(%s) RNAME(%s) RQMNAME(%s) XMITQ(%s) DEFPSIST(YES) REPLACE

или 

DEFINE QLOCAL(%s) DESCR(%s) DEFPSIST(YES) REPLACE

Ключевое слово REPLACE гарантирует, что создание не завершится неудачей, если очередь уже существует.

Я проверял этос существующей, непустой очередью, и кажется, что никакие сообщения не были потеряны.Однако этого недостаточно.Я должен быть уверен, что никакие сообщения никогда не будут потеряны или повреждены, если я введу команду DEFINE Q... REPLACE для существующей очереди.Существующая очередь может даже участвовать в транзакциях в то время.

Может ли кто-либо подтвердить или опровергнуть это поведение?

1 Ответ

2 голосов
/ 06 декабря 2011
Команда

A DEFINE с REPLACE завершается неудачно, если объект открыт.Поэтому вы не можете переопределить очередь с ожидающими транзакциями.В ручном указано , что все сообщения в очереди сохраняются в течение DEFINE с REPLACE, и это не подразумевает потери целостности сообщений.Вы можете ALTER очередь с параметром FORCE, чтобы изменить очередь, которая в данный момент открыта, как описано здесь .Это также сохраняет сообщения в очереди без потери целостности.

Команда DEFINE не повлияет на сообщения в очереди.Единственные эффекты, которые вы можете заметить, это, например, если вы измените очередь с FIFO на PRIORITY или наоборот.Это только меняет индексирование и порядок для новых сообщений в очереди и не влияет на существующие сообщения.Аналогичным образом, изменение атрибутов очереди, влияющих на дескрипторы, вступает в силу только при следующем открытии очереди.Примером этого является изменение BIND(ONOPEN) на BIND(NOTFIXED).

Одна из вещей, которые я рекомендовал некоторое время для кластеров WMQ, - это разделение определения очереди на сборку.атрибуты времени и времени выполнения.Например: 

DEFINE QLOCAL (APP.FUNCTION.SUBFUNCTION.QA) +
       GET(DISABLED) +
       PUT(DISABLED) +
       NOTRIGGER +
       NOREPLACE
ALTER  QLOCAL (APP.FUNCTION.SUBFUNCTION.QA) +
       DESCR('APP service queue for QA') +
       DEFPSIST(NO) +
       BOTHRESH(5) +
       BOQNAME('APP.FUNCTION.BACKOUT.QA') +
       CLUSTER('DIV_QA') +
       CLUSNL(' ') +
       DEFBIND(NOTFIXED)

В этом случае атрибуты GET, PUT и TRIGGER считаются исполняемыми и устанавливаются только при первом определении очереди.Это позволяет вам определить новую очередь в кластере и отключить ее, пока вы не будете готовы включить приложение.При последующих запусках скрипта эти атрибуты никогда не изменяются, поскольку в операторе используется NOREPLACE.Поэтому, как только вы включите GET и PUT в очереди, эти атрибуты (и функция приложения) никогда не будут нарушены последующими запусками скрипта.

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

Является ли какой-либо атрибут, такой как членство в кластере, временем сборки или времени выполнениярешать вам.Это всего лишь пример из многих случаев, когда администраторы непреднамеренно что-то ломали, перезапуская скрипт MQSC.

Но, чтобы ответить на ваш вопрос немного более подробно, вещи, которые ломаются, связаны с тем, что кто-то сбрасывает атрибут времени выполнения, такой как GET(DISABLED) (который может вызвать резервирование транзакции в полетеout, если приложение пытается выполнить GET в этой очереди после того, как get отключены) , а не потому, что изменение вызвало сбой целостности очереди, сообщения или транзакции.

...