#size #jms #ibm-mq
#размер #jms #ibm-mq
Вопрос:
Существует встроенное ограничение в 2 МБ для интерфейса IBM WebSphere MQ JMS.
http://www-01.ibm.com/support/docview.wss?uid=swg21221260
Есть ли способ обойти это ограничение?
Ответ №1:
Ограничение, применяемое к версиям WMQ, распространяемым с помощью, было введено в версии 5.1.1 много лет назад. Если проблема в этом, обновление WMQ до текущей версии решит ее. Текущая версия WMQ — V7.0.1. V6.0.2 также все еще актуальна, но будет прекращена в сентябре 2012 года. Версии 6 и 7 могут отправлять и получать сообщения размером до 100 МБ, но сам WMQ по умолчанию имеет размер 4 МБ из коробки. Необходимо настроить параметры QMgr, очередей и каналов, если требуются сообщения размером более 4 МБ, но JMS не является ограничением в современных версиях.
В руководствах WMQ по Java / JMS конкретно не упоминается максимальный размер, поскольку он совпадает с максимальной длиной собственного WMQ, равной 100 МБ. Однако в отчете о производительности WMQ V6 приведены контрольные показатели для сообщений JMS размером до 64 МБ.
Что бы ни мешало вам разместить сообщение размером 3 МБ, это не ограничение реализации JMS WMQ в отношении размера сообщения. Если вы проверили MAXMSGL на всех каналах и очередях и QMgr, тогда это что-то менее очевидное, но это конфигурация.
Комментарии:
1. Все это верно. Однако ограничение, на которое я ссылаюсь, касается использования интерфейса JMS, и в этом случае я не нашел способа настроить ограничение выше 2 МБ
2. Почему вы считаете, что существует ограничение в 2 МБ? Это не является частью спецификации JMS, и классы WMQ не накладывают такого ограничения. Вы получаете ошибки при попытке поместить большие сообщения? Если это так, то, вероятно, это настройка MAXMSGL в очереди, канале и / или QMgr, накладывающая ограничение.
3. смотрите ссылку в исходном сообщении:
4. Вот фрагмент из ссылки:
5. Максимальный поддерживаемый размер сообщений составляет 2 МБ. Хотя можно изменить максимальный размер сообщения на каналах, это не поддерживается. Если пользователи хотят отправлять сообщения размером более 2 МБ, им потребуется использовать внешний WebSphere® MQ.
Ответ №2:
Это может показаться сложным, но это решение:
- Возьмите содержимое вашего сообщения, преобразуйте его в массив байтов.
- Разделите массив байтов на n подмассивов размером ~< 1,9 МБ каждый.
- Запустите транзакцию JMS и отправьте каждый подмассив в виде байтового сообщения, увеличивая количество групп:
например
message.setStringProperty("JMSXGroupID", groupId);
message.setIntProperty("JMSXGroupSeq", i);
На стороне получателя вы реализуете селектор для получения всех сообщений в группе, как только получаете первое сообщение. Извлеките все сообщения в группе (надеюсь, вы получите их все), отсортируйте их правильно, заново создайте массив больших байтов, разархивируйте его, и все готово.
Действительно, тривиально…..
Вот лучший пример.
Комментарии:
1. Хотя это хороший code golf, предпосылка вопроса неверна. Надеюсь, мы сможем устранить основную причину, которая должна заключаться в настройке, а не «решать» ее путем программирования вокруг нее. Вопрос примерно эквивалентен «Как я могу заставить свой автомобиль превышать встроенный предел в 45 миль в час?» и ссылается на спецификацию Ford Model-T в качестве доказательства того, что современные автомобили не могут превышать 45 миль в час. Продолжая аналогию, этот ответ примерно эквивалентен «увеличьте мощность котла, чтобы получить большее давление пара».
2. Это отличный code golf. Кроме того, этот подход явно поддерживается WebSphere MQ: publib.boulder.ibm.com/infocenter/wmqfte/v7r0/index.jsp?topic =/… . Были ли у Ford Model-T бойлеры?
3. Right — MQFTE разделяет файлы, отправляет и повторно собирает сообщения. Но это решает другую проблему. Предпосылкой OP было то, что IBM JMS не поддерживает msgs > 2 МБ, что не только неверно сегодня, но и на момент написания упомянутой Technote было верно только для WMQ, поставляемого с WAS ! Я полностью за хорошее кодирование, если оно решает реальную проблему или все понимают, что это академическое упражнение. В этом случае OP действительно считает, что ограничение реально. Не должны ли мы помочь решить проблему конфигурации, а не позволять ему продолжать работать в условиях ложного понимания продукта?
4. При дальнейшем исследовании я вижу, что в Model-T не было бойлеров, хотя во многих машинах того времени они были. Но это еще лучше подчеркивает суть — если мы хотим решить несуществующую проблему, несуществующее решение кажется идеальным подходом.
5. Николас, К твоему сведению, я наткнулся на этот пост и отметил, что ссылка в конце больше не действительна. Я попросил IBM опубликовать его где-нибудь, но, насколько я знаю, они этого так и не сделали.