Обнаружена непредвиденная ошибка данных при одновременном получении BizTalk

Question

У меня есть порт приема с двумя местами приема FILE, опрашивающими один и тот же сетевой ресурс. Единственная разница между местами приема состоит в том, что они используют другую маску файла. Оба они используют собственный конвейер с одним компонентом дизассемблера плоских файлов. У меня есть порт отправки, подписывающийся на порт приема. (это просто минимальная настройка, в которой я могу воспроизвести проблему).

При обработке группы файлов (размером до 1 МБ) иногда конвейер выдает ошибку. Это происходит только тогда, когда более одного файла копируется в общую папку получения файла и происходит нерегулярно. Ошибка обычно гласит:

Произошла ошибка при разборе входящего документа: «Неожиданные данные найдено при поиске: '\ r \ n' Текущее определение, которое анализируется: GIRMFile. Смещение потока, в котором произошла ошибка, составляет 491540. номер строки, в которой произошла ошибка, - 2446. Столбец, в котором произошла ошибка 199 ".

Изучение приостановленного сообщения по указанному номеру строки, последовательно 512 байт данных, отличается от входящего сообщения. Эти 512 байтов данных всегда соответствуют данным из одного из других входных файлов, потребляемых одновременно! Или в нескольких редких случаях неправильные 512 байт данных - это данные из файла, потребляемого в одно и то же время, но после того, как он был обработан конвейером (то есть приостановленный плоский файл имеет 512-байтовый фрагмент xml!). 512 байт никогда не находятся в согласованном месте в приостановленных сообщениях.

Думая, что базы данных BizTalk каким-то образом повреждены, я удалил их и перенастроил. Проблема вернулась после того, как несколько сотен файлов были успешно обработаны.

Это происходит только на нашем тестовом компьютере (VMWare vm), поэтому я подозреваю, что проблема с машиной в некотором роде. Но кажется странным, что машина не сообщает о других ошибках в других процессах.

Answer 1

Это происходит только на нашем тестовом компьютере (VMWare vm)

Если вам не удастся воспроизвести это на другом компьютере с такой же конфигурацией, я бы пометил это как не проблемный или внешний. Согласитесь с вышеизложенным, что проблемы параллелизма крайне маловероятны

Answer 2

Интересно - я помню, как видел подобные вещи в BizTalk 2004, но ничего подобного не видел с BT2006.

Похоже, что конвейер может столкнуться с проблемами потоков - возможно, из-за получения файлов из одного и того же местоположения файла.

Вы пробовали какие-либо из расширенных свойств местоположения получения файла?

Я имею в виду, в частности, флажок «Переименовать файлы во время чтения». Возможно, если проблема связана с потоковыми чтениями без потоков, этот процесс создания переименованного файла (который, я думаю, использует только стандартные библиотеки ввода-вывода) позволит BizTalk получить чистый поток.

Только догадываться - пожалуйста, сообщите, если найдете решение!

Answer 3

У нас аналогичные проблемы с программами, работающими на виртуальных машинах VMWare, обращающихся к общим ресурсам. По какой-то причине файлы окажутся поврежденными.

Это не было связано с BizTalk, это происходило с приложением, разработанным внутри компании.

Перезагрузка виртуальной машины на некоторое время решает нашу проблему. В нашем случае мы смогли перенастроить наш процесс, чтобы не использовать общие ресурсы. Мы никогда не пытались найти решение настоящей проблемы.

Answer 4

Еще несколько мыслей ... это доля DFS? Можете ли вы разместить места приема на разных хостах и ​​посмотреть, что произойдет потом?

Answer 5

Вы сказали, что сеть получения местоположения является сетевым ресурсом - возможно, это проблема сети? Можете ли вы воспроизвести это на локальном диске?

Answer 6

Должен сказать, что я нахожу это очень странным, мне было бы очень трудно поверить, что через 5 лет работы в BizTalk (считая с 2004 года :-)) адаптер FILE и стандартные дизассемблеры имеют проблемы с потоками.,

Поступают ли файлы в место получения по сети? какие маски файлов вы используете? Есть ли вероятность того, что одно из мест получения получает файлы до завершения их передачи?