MQ - обработка сообщений, превышающих максимальную длину, переходящих в очередь ожидания - PullRequest
0 голосов
/ 28 июня 2018

Это общий вопрос. Позвольте мне сказать, что у меня есть менеджер очередей локально. У меня есть настройка определения очереди передачи / удаленной очереди, через которую я подключаюсь к очереди администратора очередей назначения. Если максимальная длина сообщения в очереди администратора очередей равна 1000, и если я добавлю длину сообщения больше этой, она автоматически переместится в очередь недоставленных сообщений администратора очередей, при условии, что максимальная длина сообщения в очереди передачи превышает введенную мною. Это ожидаемое поведение. Но есть ли способ в мире MQ справиться с этим и не переместить его в мертвую очередь? Или приложение несет исключительную ответственность за то, чтобы это сообщение не превышало максимальную длину?

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 29 июня 2018

Спасибо, Роджер и JoshMc. Фактически я попробовал оба варианта, клиент к QM и между QM и QM. Клиент к QM в порядке, так как клиент получает код ошибки и в основном ничего не происходит. Но проблема только между QM отправителя и QM получателя. Чаще всего я видел, что будет только одна очередь передачи с максимальной длиной сообщения для соединения с конкретным администратором очередей. Все различные удаленные соединения / очереди используют эту очередь передачи. Таким образом, если отправитель совершает ошибку, отправляя большое сообщение, чем очередь назначения не может принять, он обычно проходит через очередь передачи, но терпит неудачу в пункте назначения и достигает мертвой очереди пункта назначения. Теперь владелец пункта назначения предупрежден / или ему необходимо принять меры по исправлению ошибки, которую он не совершил. Вот и вся причина, по которой я задаю этот вопрос. Большое спасибо вам обоим за то, что вы пролили больше света и потратили на меня время.

Я думаю, что Мораг Хьюсон дал мне кое-что попробовать, но, тем не менее, это будет иметь свои негативные последствия. Но я искал что-то подобное, где мы могли бы контролировать на уровне MQ, чтобы сообщение не отправлялось в мертвую очередь назначения.

0 голосов
/ 28 июня 2018

Изменение максимальной длины сообщения по умолчанию (т. Е. MAXMSGL) с 4 МБ на небольшое значение - плохая идея.

Миф: MQ НЕ выделяет пространство на основе значения в поле максимальной длины сообщения. Установка очень маленького значения или очень большого значения не влияет на дисковое пространство. MQ ТОЛЬКО записывает размер / количество реального сообщения.

Во-вторых, команда приложения должна сообщить MQAdmin, какое самое большое сообщение будет отправлено приложением. Если они говорят 10 МБ, то MQAdmin может увеличить макс. длина сообщения до 10 МБ или что-то немного больше, то есть 12 МБ.

Наибольшее значение, которое можно использовать, составляет 100 МБ.

Примечание: MQAdmin нужно будет увеличить макс. длина сообщения для: канала, XMITQ, локальной очереди и очереди недоставленных сообщений для любого сообщения, размер которого превышает размер по умолчанию 4 МБ, иначе оно не будет передаваться.

...