У нас странная проблема с Indy10, когда две большие строки (по несколько сотен символов каждая), которые мы посылаем одну за другой с помощью TCP, появляются на другом конце, странным образом переплетенными. Это случается крайне редко.
Каждая строка представляет собой полное сообщение XML, оканчивающееся LF, и в общем случае процесс READ считывает сообщение XML целиком, возвращаясь, когда видит LF.
Вызов для фактической отправки сообщения защищен критической секцией вокруг вызова метода IOHandler writeln, и поэтому два потока не могут отправлять одновременно. (Мы уверены, что критический раздел реализован / работает должным образом). Эта проблема случается очень редко. Симптомы странные ... когда мы отправляем строку A, за которой следует строка B, то, что мы получили на другом конце (в тех редких случаях, когда у нас происходит сбой), представляет собой конечную часть строки A (, т.е. ). , в конце есть LF), за которым следует начальный раздел строки A, а затем вся строка B, за которой следует один LF. Мы убедились, что свойство «timed out» не соответствует действительности после частичного чтения - мы регистрируем это свойство после каждого чтения, которое возвращает содержимое. Кроме того, мы знаем, что в строке нет встроенных символов LF, поскольку мы явно заменяем все не алфавитно-цифровые символы в строке пробелами перед добавлением LF и его отправкой.
У нас есть механизмы регистрации внутри критических секций как на передающей, так и на принимающей сторонах, и поэтому мы можем увидеть это поведение на «проводе».
Мы полностью сбиты с толку и задаемся вопросом (хотя всегда с наименьшей вероятностью), могут ли быть какие-либо проблемы Indy низкого уровня, которые могут вызвать эту проблему, например , буферы отправляются в неправильном порядке. ... очень трудно поверить, что это может быть проблемой, но мы цепляемся за соломинку.
У кого-нибудь есть яркие идеи?