Системная ошибка SQL Server Service Broker -9616, когда это может произойти?

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

  • один тип сообщения, который отправляется только инициатором (VALIDATION = WELL_FORMED_XML, без XSD)
  • один контракт с этим типом сообщения
  • оба развернуты на стороне инициатора и цели (удаленные машины)

Иногда я нахожу сообщения об ошибках системы Service Broker в целевой очереди, например:

<Error xmlns="http://schemas.microsoft.com/SQL/ServiceBroker/Error"><Code>-9616</Code><Description>A message of type 'here_is_the_name' was received and failed XML validation.  XML parsing: line 1, character 547, illegal xml character This occurred in the message with Conversation ID 'here_is_the_guid', Initiator: 1, and Message sequence number: 0.</Description</Error>

Я просмотрел запись в блоге Ремуса Русану, и он утверждает, что:

Эта системная ошибка отправляется в диалог, который отправил тип сообщения, помеченный как соответствующий определенной схеме XML, но полезная нагрузка не смогла пройти проверку XML для указанной схемы.

В моем случае нет задействованной схемы XML, и я пытался воспроизвести этот случай в моем окружении разработки, используя те же версии SQL Server, и мне не удалось это сделать.

Я хотел бы знать, возможно ли получить это сообщение об ошибке системы, хотя я не использую схему XSD? Если да, то когда это может произойти, каков сценарий, при котором компонент Service Broker генерирует ошибку, как указано выше?

В сообщении четко написано: «Разбор XML: строка 1, символ 547, недопустимый символ xml», поэтому, на мой взгляд, это не имеет ничего общего с проверкой схемы. Может ли быть, что на транспортном уровне возникают некоторые проблемы (ошибки TCP), и поэтому Service Broker генерирует это сообщение об ошибке?


sql-server-2008 sql-server-2005 service-broker
person LSZ    schedule 14.11.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Проверка сообщения происходит при постановке сообщения в целевую очередь, а не при отправке. Проверка типа сообщения (NONE, XML, XDS) предоставляется для защиты вашего приложения. Валидации во время SEND недостаточно, так как вредоносное приложение может отправить сообщение без использования Service Broker (имитатора протокола проводной связи). Поскольку проверка во время постановки в очередь является обязательной, добавление проверки во время SEND немного увеличило бы нагрузку на ЦП.

Это означает, что ваше приложение на стороне SEND отправляет недопустимый XML, и это перехватывается целевой стороной. Формулировка в моем блоге выбрана неудачно, я должен был более четко указать, что проверка может привести к сбою схемы (если указана) или к хорошо сформированный XML-тест.

Можете ли вы опубликовать тело сообщения, которое вы отправляете?

person Remus Rusanu    schedule 14.11.2014
comment
Спасибо, Ремус, за ответ. Я понимаю первую часть и знаю, что SSB работает таким образом, проверка при постановке в очередь имеет смысл. Вторая часть немного смутила меня, потому что я всегда знал (например, это было представлено в вашем блоге о шаблоне «огонь и забыть»), что если инициатор отправляет сообщение, а цель не принимает его, потому что, например, это недействительный XML, цель отправит сообщение об ошибке инициатору. Это именно то, что я наблюдал много раз, но в случае, описанном в этой проблеме, сообщение об ошибке находилось в целевой очереди, и это односторонний обмен сообщениями. - person LSZ; 18.11.2014
comment
К сожалению, я не могу опубликовать тело сообщения, так как это происходит в нашем производстве, и, к сожалению, изначально приложение EAI, которое использует Service Broker внизу, было развернуто с шаблоном Fire and Forget (да, я знаю, что это очень плохо, я пытаюсь повлиять на некоторые люди, чтобы изменить это). Так что в моем случае даже поворот ретенции бесполезен. - person LSZ; 18.11.2014
comment
Сообщение, находящееся в целевой очереди, означает, что существует ответ (недопустимый XML) от цели, который отвергается инициатором. Еще раз проверьте целевой код. Отслеживайте Broker: класс событий разговора. - person Remus Rusanu; 18.11.2014
comment
Я развернул свою конфигурацию рабочего разговора на dev и протестировал то, что вы предложили. Поскольку это односторонний обмен сообщениями, и, как описано выше, в контракте говорится, что только инициатор может отправить сообщение, пытаясь ответить от полученной мной цели: Msg 8434, Level 16, State 1, Line 1 Сообщение не может быть отправлено, потому что тип сообщения "msg_type_name" помечен в контракте SENT BY INTITIATOR, однако эта служба является Target. - person LSZ; 19.11.2014