Websphere MQ, получить большое (100 МБ) сообщение

Question

Я пытаюсь прочитать файл 100 МБ из очереди MQ Websphere. Файл должен содержать ок. 800 000 записей. Но после некоторого номера строки (обычно около 90 000) я получаю только пустой (или, возможно, & # 65533, в зависимости от того, как я пытаюсь просмотреть файл).

Мне сказали, что в очереди должно быть 100 МБ сообщений.

Мой код:

  var mqQueueManager = getMqQueueManager(ConfigurationManager.AppSettings["MQ_QueueManager"]); 
      var mqQueue = mqQueueManager.AccessQueue(mqReceiveQueueName, 
                 MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_FAIL_IF_QUIESCING); 

      MQGetMessageOptions gmo = new MQGetMessageOptions(); 
      gmo.Options = MQC.MQGMO_NO_WAIT; 

      for (int i = 0; i < maxMessagesToRead; i++) 
      { 
       var mqMessage = new MQMessage(); 
       mqQueue.Get(mqMessage, gmo); 

       messageTexts.Add(mqMessage.ReadString(mqMessage.MessageLength)); 
      } 

Что-то не так с этим кодом? Или ошибка на стороне отправки?

Answer 1

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

Я пытаюсь прочитать файл 100 МБ из очереди MQ Websphere. Файл должен содержать ок. 800 000 записей. Но после определенного ряда числа (обычно около 90.000)

Hidden в этом одном заявлении ссылки на:

• Файлы
• Очереди
• Записи
• Ряды

Я уверен, что каждый, кого вы попросили, отвечает что касается очередей, поэтому повторяются заверения в том, что MQ может обрабатывать сообщения в 100 МБ. Но код, похоже, собирает файл , который был разделен на одну запись/строку за сообщение. Это совершенно другой вариант использования.

Принимая это за один раз, в MQ вполне возможно передать сообщения 100 МБ взад и вперед. Для этого требуется, чтобы каждый QMgr, канал и очередь по этому пути настраивались с 4MB по умолчанию для MAXMSGL. Менее очевидно, что для использования нескольких транзакций на 100 Мбайт должно быть достаточно лог-пространства, если вы используете линейные журналы и/или сообщение обрабатывается под синхронизацией. Количество и размер журнала журнала по умолчанию не предполагают 100 МБ сообщений. Наконец, приложение должно предоставить достаточно большой буфер и не указывать MQ, чтобы разрешить усеченные сообщения.

Этот способ перемещения файлов по MQ ограничен файлами менее 100 МБ, но имеет явное преимущество атомных операций - либо вы GET/PUT весь файл, либо вообще ничего. Нет недостающих частей, ничего не по порядку и т. Д. Это значительно упрощает код.

Вторая возможность заключается в том, что код повторно собирает файл, который был разделен на многие сообщения. Кажется сомнительным, что опубликованный фрагмент кода действительно хочет добавить несколько сообщений 100 МБ друг другу, поэтому я предполагаю, что он пытается собрать файл из многих сообщений. (Кажется, до 800 000.) В этом случае проблема заключается в том, сколько сообщений может быть в одной единице работы. Фрагмент кода не содержит каких-либо значимых ошибок обработки, поэтому я предполагаю, что обработка с использованием синхронизации также была опущена.

Среди ошибок, возникающих при сборке файла, являются сообщения о непостоянстве и отсутствующие сообщения.Даже самый простой простой файловый движок, основанный на MQ, который использует несколько сообщений для каждого файла, должен будет использовать точку синхронизации, чтобы гарантировать, что весь файл отправлен или принят как единое целое. Но MQ не ожидает 800 000 сообщений в одной единице работы, поэтому вам нужно будет настроить как размер журнала , так иMAXUMSGS сделать что-нибудь большее, чем тривиальный случай.

Конечно, перемещение файлов и обеспечение их целостности, когда они разделены на многие сообщения, не являются тривиальными, и к тому времени, когда все перестановки учитываются, результат выглядит так же, как MQ Managed File Transfer.

Возвращаясь к вопросу, если файл транспортируется в одного сообщения и опции API укоротить сообщения не установлен, то нет ничего в API MQ, которые будут влиять на сообщение после некоторого количества строк или длины сообщения. В этом случае единственный способ объяснить, как получить мусор мимо определенного момента, - отправить отправителю приложение. (Например, выделенный буфер 100 МБ, заполненный 50 МБ, затем отправленный сообщение 100 МБ.)

Однако, если файл разбит на многие сообщения, как показано в коде, необходимо выполнить настройку, упомянутую выше. Это включало в себя наталкивание MAXUMSGS на значение, превышающее 800 000 (doc link), и обеспечение достаточного пространства в первичных и вторичных объемах журналов для хранения нескольких больших единиц работы. См. Calculating the size of the log.

Как и в сторону, вы также можете переустанавливать MQGMO каждый раз, потому что, как отмечалось в Overview для этого объекта, она является как вход и выход.

Модифицированный код будет выглядеть следующим образом:

  MQGetMessageOptions gmo = new MQGetMessageOptions(); 

      for (int i = 0; i < maxMessagesToRead; i++) 
      { 
       var mqMessage = new MQMessage(); 
       gmo.Options = MQC.MQGMO_NO_WAIT; 
       mqQueue.Get(mqMessage, gmo);