Есть древняя система, до которой пока не доходят руки переделать.
При проведении документа параллельно проводится документ в другой системе через COM. Документы проводятся из обработки через попытка/исключение (чтобы сбои проведения одного не мешали попытаться обработать остальные в списке). Обе системы - толстый клиент. И с некоторых пор появилась проблема.
В процессе проведения документа периодически (закономерности не выявлено) вылетает исключение "Удаленный хост принудительно разорвал существующее подключение". Ну, классическая 10054.
Обычно при такого рода ошибках крашится сеанс, а тут нет. То есть похоже что это исключение записи через ком-соединение, а не родного сеанса. Хотя тоже натянутая гипотеза - ниже будут данные против нее.
Но это пол-беды. Беда в том, что исключение-то вылетает. Но сама запись в удаленной системе (куда по COM писалось) происходит успешно и в ее ЖР все чин-чинарем: подключились, провели, отключились.
И в итоге беда. В приемнике транзакция успешна, а в источнике - нет.
Как-то я эту проблему решу. Через ТЖ ловить тяжело будет. В крайнем случае выбьем время и перепишем на сервисы. Смущает, что я не понимаю что происходит.
Каким гребаным хером это исключение умудряется вылетать при успешной транзакции через СОМ? И почему оно не фиксируется в базе приемника? Более того, в базе приемника последующие ком-подключения идут в рамках того же сеанса если верить ЖР. То есть не крашится ни сеанс в источнике ни сеанс в приемнике. Но тогда какое такое подключение разрывает "удаленный хост"?? Ненавижу такие непонятки.

Выход: отказаться от COM

Да блин работало годами без проблем. Не хотелось бы сейчас ради этой внезапной хери рушить график работ.

пррова?

Самый надёжный - файловый обмен:) СОМ для отчётов хорош сличения данных

(0) Версию клиента 1С огласи, случаем не 8.3.18.хххх ?

Через сом передают или получают данные. Но вот еще и проводить это уже слишком кажется.
И самое главное при проведении тут чтоб там провелся! Это же адский ужасный подход.

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

А что автора удивляет? Транзакция закоммитилась в приемнике, а до источника (инициатора) этот флаг успеха не дошел из-за любого сбоя в передаче данных (возврата управления инициатору).

Ком по таймауту в 30 сек отвалился?

(7) Автора удивляют начавшиеся регулярные сбои, попадающие в аккурат на интересный момент - сразу после успешной транзакции.
(8) Хм... Проверю. А как увеличить таймаут, если что?

(9) А что по ЖР, какова там длительность у входящих СОМ-сеансов (которые потом в источнике падают)?