Имя: Пароль:
1C
 
Мобильное приложение (Extra content of the end of the document.)
0 Zyka
 
20.12.14
18:15
Доброго времени суток, дорогие друзья.

Перейду сразу к делу.

Мобильное приложение на платформе 8.3.5.1186
Сервер на платформе 8.3.4.389
Мобильная платформа (arm) 8.3.5.74
Веб-сервер: IIS 7.5.7600.16385

Среднее количество активных пользователей мобильного приложения 30-40.

Обмен с сервером через WS.

Среднее количество запросов Клиент-Сервер через WS 20-30/мин.

Периодически у некоторых(!) пользователей возникает ошибка:
"1С Предприятие. Ошибка Разбора XML: - [1,1] Фатальная ошибка: Extra content of the end of the document.".

В траффике передаются как сериализованные данные 1С, так и типы w3 (например BinaryData).

Не могу однозначно выяснить причину ошибки.

Отладка и стресс-тесты ошибок не выявили.

Если кто-то сталкивался или может навести на проблему буду очень благодарен.

Спасибо.
1 Zyka
 
20.12.14
18:17
P.S.
Под сериализованными данными 1С, разумеется подразумевается XML.
2 Garykom
 
гуру
20.12.14
18:19
(0) канал рвется? при передаче XML-ны?
3 Zyka
 
20.12.14
18:35
(2) - предположение имеет место быть. Т.к. пользователи используют 2/3G. Однако на стороне сервера и XDTO-пакета, было установлено ограничение на объем данных.
Пойду перепроверять.
Спасибо.
4 DitriX
 
21.12.14
16:31
эта ошибка - не значит что проблемы со связью, это может быть ошибка и десериализации, или записи данных.
К примеру - не верный порядок загрузки данных.

Так что вполне можно создать регистр сведений куда пихать сообщения из попытки/исключения при загрузке данных.

Ну и. ясное дело. потом уже не будете тыкать пальцем в небо.

То что эта ошибка не связанна с разрываом сети - руб за сто даю.

Вы же не юзаете udp пакеты для передачи данных. Так что 1С таки однозначно получает ответ, тем более что она сама сжимает данные, так что там не может быть такого, что она часть данных не догрузит. Если такое случится - будет ошибка соединения, а не прасинга.
5 Zyka
 
23.12.14
12:40
Проблема была в одном из фасетов XDTO-пакета.

На фасете с типом "string" было установлено ограничение в 65536 знаков.
В момент сериализации данных на стороне сервера, SOAP не выдавал ошибку на превышение и просто не дописывал ответ, из-за чего была ошибка десериализации на клиенте.

Так как сераилизованные данные не подвергаются компрессии (встроенными функциям) и XML становиться > 100кб, перевел все на ValueStorage с уровнем сжатия 9.

Полет нормальный.

Всем откликнувшимся - спасибо!
6 DitriX
 
25.12.14
01:28
ЧТД:) Но вы хоть поведайте - как вычислили?
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн