запрос сообщений и размещение в проблемах возврата

Я застрял со следующей проблемой с сообщением Broker 7.0.0.5 Вот мой поток:

поток

что я хочу, чтобы он сделал: 1. принял XML, проанализировал, используя XMLNSC 2. затем я хочу, чтобы была выполнена некоторая бизнес-логика, но давайте пропустим это и сосредоточимся на следующем - я хочу создать два пользовательских исключения - одно в модуле GoodReport, еще один - в модуле BadReport, поэтому после обработки в обоих потоках Out и Catch я предполагаю, что мое сообщение попадет в очередь возврата (я создал ее для своей очереди и установил для Threshold значение 10) и отправить обратно в MQInput для повторной обработки. Итак, я ожидаю 10 сообщений в очереди Backout, но вместо этого - НИЧЕГО не получаю

Я вижу, что в моем потоке возникают обе ошибки, но больше всего меня удивляют последние строки в трассировке — откуда появился этот домен «XMLNS»? Я использую только домен XMLNSC.

А почему сообщение не появляется в очереди Backout?

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

Татьяна.

вот след:

2012-12-17 19:25:54.692283 5756 RecoverableException BIP2488E: ('.Esql6_1Flow_Report.Main', '19.4') Обнаружена ошибка при выполнении инструкции SQL ''ОТКАЗАТЬ СООБЩЕНИЕ ОБ ИСКЛЮЧЕНИИ 3 ЗНАЧЕНИЯ( 'NO_SUCH_SOURCE ');''. Брокер сообщений обнаружил ошибку при выполнении данного оператора. Было создано исключение, чтобы прервать программу SQL. Дополнительные сведения об ошибке см. в следующих сообщениях.

2012-12-17 19:25:54.692302 5756 UserException ?????????? 3 ???????????? BIPmsgs.properties 17-12-2012 19:26:52.830982 5756 Ошибка BIP2628E: на входном узле «Esql6_1Flow.MQInput» обнаружено условие исключения. Входной узел «Esql6_1Flow.MQInput» обнаружил ошибку при обработке сообщения. Поток сообщений откатился, и, если сообщение обрабатывалось в единице работы, оно останется во входной очереди для повторной обработки. Следующие сообщения укажут причину этого исключения. Проверьте следующие сообщения об ошибках, чтобы определить, почему было создано исключение, и примите меры, описанные в этих сообщениях.

2012-12-17 19:26:52.831005 5756 RecoverableException BIP2230E: обнаружена ошибка при обработке сообщения в узле «Esql6_1Flow.BadReport». Брокер сообщений обнаружил ошибку при обработке сообщения в узле «Esql6_1Flow.BadReport». Создано исключение, чтобы сократить обработку сообщения. Дополнительные сведения об ошибке см. в следующих сообщениях.

2012-12-17 19:26:52.831012 5756 RecoverableException BIP2488E: ('.Esql6_1Flow_Compute.Main', '13.4') Обнаружена ошибка при выполнении оператора SQL ''ОТКАЗАТЬ СООБЩЕНИЕ ОБ ИСКЛЮЧЕНИИ 3 ЗНАЧЕНИЯ( 'NO_SUCH_SOURCE ');''. Брокер сообщений обнаружил ошибку при выполнении данного оператора. Было создано исключение, чтобы прервать программу SQL. Дополнительные сведения об ошибке см. в следующих сообщениях.

2012-12-17 19:26:52.831020 5756 UserException ?????????? 3 ???????????? BIPmsgs.properties

2012-12-17 19:26:53.831737 5756 Ошибка BIP2648E: сообщение возвращено в очередь; узел «Esql6_1Flow.MQInput». Узел «Esql6_1Flow.MQInput» получил сообщение, которое ранее было отклонено один или несколько раз из-за ошибки обработки на основном пути потока сообщений. Терминал сбоя не подключен, поэтому брокер сообщений помещает сообщение непосредственно в очередь повторной очереди или очередь возврата недоставленных сообщений, связанную с этим узлом. 'backoutCount' сообщения MQMD теперь равен 'backoutThreshold', определенному для входной очереди WebSphere MQ. Изучите предыдущие сообщения и поток сообщений, чтобы определить, почему сообщение отменяется. Исправьте эту ситуацию, если это возможно. Выполните любую необходимую локальную обработку восстановления после ошибки.

2012-12-17 19:26:53.832435 5756 UserTrace BIP2638I: выходной узел MQ "Esql6_1Flow.MQInput" попытался записать сообщение в очередь "SYSTEM.DEAD.LETTER.QUEUE", подключенную к диспетчеру очередей "testQueueManagerName" . MQCC был «0», а MQRC был «0».

2012-12-17 19:26:53.832466 5756 UserTrace BIP2615I: входной узел WebSphere MQ "Esql6_1Flow.MQInput" возвратил сообщение в очередь возврата или очередь недоставленных сообщений. Была запущена обработка возврата сообщения, и сообщение было либо отозвано путем записи в очередь возврата или очередь недоставленных сообщений, как определено администратором очередей WebSphere MQ и конфигурацией очереди. Никаких действий пользователя не требуется.

17.12.2012 19:27:31.087949 4380 UserTrace BIP2632I: сообщение получено и передано на «выходной» терминал входного узла MQ «.InputNode».

2012-12-17 19:27:31.088045 4380 UserTrace BIP6060I: Тип синтаксического анализатора «Свойства», созданный от имени узла «.InputNode», для обработки части входящего сообщения длиной 0 байт, начиная со смещения «0».

2012-12-17 19:27:31.088066 4380 UserTrace BIP6061I: Тип синтаксического анализатора «MQMD» создан от имени узла «.InputNode» для обработки части входящего сообщения длиной «364» байта, начиная со смещения «0». Тип синтаксического анализатора выбран на основе значения ''MQHMD'' из предыдущего синтаксического анализатора.

2012-12-17 19:27:31.088092 4380 UserTrace BIP6069W: брокер не может обрабатывать сообщения типа данных ''''. Посредник сообщений получил сообщение, которое требует обработки данных типа '''', но у посредника нет возможности обрабатывать данные этого типа. Проверьте как сообщение, отправляемое брокеру сообщений, так и данные конфигурации узла. Ссылки на неподдерживаемый тип данных должны быть удалены, если сообщение должно обрабатываться посредником.

2012-12-17 19:27:31.088113 4380 UserTrace BIP6061I: тип парсера ''XMLS'' создан от имени узла '.InputNode' для обработки части входящего сообщения длиной «236» байт, начиная со смещения «364». Тип анализатора выбран на основе значения ''XMLS'' из предыдущего анализатора.


person tania    schedule 17.12.2012    source источник
comment
Сообщение будет помещено в очередь возврата только после того, как счетчик возврата превысит порог возврата. Возможно, вы захотите перепроверить количество Bacout сообщения.   -  person Shashi    schedule 18.12.2012


Ответы (1)


Счетчик BACKOUT определяет, сколько раз поток должен повторить попытку обработки сообщения. Здесь пороговое значение установлено равным 10, что означает, что поток пытается выполнить обработку 10 раз, и если это все еще не удалось, узел MQInput поместит сообщение в очередь возврата или DLQ, если очередь возврата не настроена. Flow поместит в очередь возврата только одно сообщение, а не 10 сообщений, как вы ожидаете.

Если сообщения обрабатываются в нетранзакционном режиме, то поток не будет помещать сообщение в очередь возврата. Проверьте, настроили ли вы свойство Transactional как «НЕТ» в узле MQInput. Если настроено значение «Автоматически», то сообщение должно быть постоянным, чтобы оно могло быть обработано в рамках транзакции. Но фрагмент трассировки показывает, что сообщение помещено в SYSTEM.DEAD.LETTER.QUEUE. Вам может потребоваться проверить, находится ли сообщение в DLQ, а также убедиться, что свойство очереди возврата правильно настроено во входном узле.

Прочтите на http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ac00414_.htm ответит на все ваши вопросы.

person james    schedule 18.12.2012
comment
Большое Вам спасибо. Настоящая проблема была очень проста - я создал очередь Backout для очереди вывода, а не для очереди ввода. - person tania; 20.12.2012