8.х Проблема с зависанием 1С при выполнении обработки

А

Жестоко - нет. А по делу я не всегда. У мну тоже весна и шизы обостренье.

Прах в землю, от праха азот, от азота - корнеплоды. Корнеплоды съешь - потом в туалет. Короче чем был - тем и останусь

Уменьшить нельзя т.к. всплывает косяк только на рабочих (больших) объемах.
Если бы глючили алгоритмы событий-подписок, то зависание всплывало бы регулярно, нет ? И потом, идет вызов проведения документа, он проводится и обработка работает дальше, делая запись в лог, это разве не показатель того что обработчики событий непричем ?

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

Вот кстати да, тут вы правы, надо будет переделать.

А по второй строке, как еще искать дубли и избавляться от них ?
Хотя данную проверку можно вырубить.

Но вряд ли виснет из-за этого.

Что логично наталкивает на мысли о неоптимальном коде.

Иной раз я водки четвертуху выпью - и огурцом. А иной раз 50 грамм - и пополз под куст.
Как вариант: во время работы программы срабатывает другая программа (а вот например фоновое задание), которая и вступает в конфликт. На мелких партиях вероятность одновременного исполнения программ - меньше (теория игр называца или массового обслуживания - чем больше время обработки запроса, тем выше вероятность возникновения очереди).

Ну это мне, например понятно и знакомо.
Потому и говорю отладчик а не переписчик.
Вы говорите что программа отрабатывает и на точку выхода попадает, а я вот в этом сумлеваюсь.

Пардон за аналогию, но вот я зашел в туалет. Все дела сделал - да, но говорит ли это о том, что из туалета я вышел? А вот нет! Потому как ноутбук, wi-fi, письмена на освежителе, мысли о вечном.
Так вот, чтобы точно знать что я начал выходить из туалета - нужно датчик на выходе (внутри туалета поставить). А чтобы понять что из туалета я при этом вышел - нужен еще и датчик на выходе за туалетом (а том мож я в дверях где застрял, опять задумался)

А сначала считать файл целиком в память, и лишь потом приступить к обработке считанных данных - вариант?

Фоновые - это регламентные ? Если да, то они отключены настройках сервера.

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


Тут ситуация во многом еще и теоретическая. Данная проблема до недавнего времени проявлялась редко и была неприоритетной. Но вот остальные вопросы решены, а данный косяк стал вылазить, вот и решаю, притом, что процедуру во время всех доработок не трогал. Опять же проблема, когда я запускаю загрузку у заказчика на сервере, все нормально или почти нормально, а когда человек заказчика на том же сервере (соотв. другой пользователь и т.д.) но в другой базе, то у него 1 из 2 запусков идет с зависанием.

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

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

Нет, делать один большой документ я точно не буду, его же хрен откроешь, даже непроведенный.

Виснет в обеих, но с разной частотой. Я не админ и влияния на него не имею, все что я могу сделать - сказать представителю заказчика, что это надо посмотреть, что и было сделано когда разница стала очевидной.

Программист

На правах восстановления темы.

Вопрос так и не решился. В моем случае ошибка идентичная что и у Pilot2903.

Добрый день.
Платформа 8.3.5.1443. Модуль собственной разработки.

Ошибка в следующем, в определенной ситуации (не диагностируемой), после выполнения процедуры &НаСервереБезКонтекста, которая возвращает «массив структур» для дальнейшего заполнения табличной части справочника в момент когда производится отключение от сервера (КонецФункции) и возврат НаКлиента система «мифически» зависает и не передает управление Клиенту. Другими словами система зависает.

В некоторых справочниках все отлично, в некоторых зависает.

Что я предпринял:
1. Вынес все выводы сообщений из процедуры;
2. Вывел из контекста формы, перенес НаСерверБезКонтекста, ранее заполнял табличную часть в процедуре &НаСервере методом Загрузить();
3. Установил привилегированный режим.

Укажите куда копать?

forum.mista.ru/topic.php?id=733645

воздержитесь от прямых ссылок