Запрос сообщения и размещение в вопросах отказа
Я застрял со следующей проблемой с сообщением 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 ' 'THROW EXCEPTION MESSAGE 3 VALUES(' NO_SUCH_SOURCE ');'. Посредник сообщений обнаружил ошибку во время выполнения данного оператора. Возникло исключение для прекращения работы программы SQL. См. Следующие сообщения для подробной информации об ошибке.
2012-12-17 19: 25: 54.692302 5756 UserException?????????? 3?????????? BIPmsgs.properties 2012-12-17 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 ' 'THROW EXCEPTION MESSAGE 3 VALUES(' 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" получил сообщение, которое ранее было отменено один или несколько раз из-за ошибки обработки в основном пути потока сообщений. Терминал сбоя не подключен, поэтому брокер сообщений помещает сообщение непосредственно в очередь возврата или очередь отклоненных писем, связанную с этим узлом. MQMD backoutCount сообщения теперь равно 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 и конфигурацией очереди. Никаких действий пользователя не требуется.
2012-12-17 19: 27: 31.087949 4380 UserTrace BIP2632I: Сообщение получено и передано на терминал "out" входного узла 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'' из предыдущего парсера.
1 ответ
Счетчик BACKOUT определяет, сколько раз поток должен повторить обработку сообщения. Здесь пороговое значение установлено равным 10, что означает, что поток пытается выполнить обработку 10 раз, и если он все еще не выполнен, узел MQInput поместит сообщение в очередь возврата или DLQ, если очередь возврата не настроена. Поток поместит только одно сообщение в очередь отклонения, а не 10 сообщений, как вы ожидали
Если сообщения обрабатываются в нетранзакционном режиме, поток не будет помещать сообщение в очередь возврата. Проверьте, настроили ли вы свойство Transactional как "NO" в узле MQInput. Если задано значение "Автоматически", то сообщение должно быть постоянным, чтобы обрабатывать его в рамках транзакции. Но фрагмент трассировки показывает, что сообщение помещено в SYSTEM.DEAD.LETTER.QUEUE. Может потребоваться проверить, находится ли сообщение в DLQ, а также убедиться, что свойство очереди возврата правильно настроено во входном узле.
Прочитайте на http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ac00414_.htm это ответит на все ваши запросы.