Ошибки блокировок

[berezdetsky]

Набрёл на ситуацию: в ЖР периодически появляется по несколько десятков записей

{ОбщийМодуль.мзЗадания.Модуль(564)}: Ошибка при вызове метода контекста (Прочитать)
по причине:

по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки

В регистре мзЗадания при этом остаётся такое же количество заданий в статусе "Ожидает выделенного исполнителя". 564 строка - это функция ПолучитьЗаполненныйНаборЗаписейПоКлючуЗадания в версии 1.4.3.

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

Повторяемый тест не смогу.

[wizi4d]

А понятно с какими заданиями это происходит?
Только те, что в статусе "Ожидает выделенного исполнителя"? С сервером 1С при этом что происходит?
Теоретически такое может произойти, только если одновременно стартанул выделенный исполнитель и в это же время задание было взято в работу через менеджера

[berezdetsky]

С сервером происходит нагрузочно-интеграционный тест. :)

Получается примерно так: в транзакции в большом количестве вызывается ДобавитьЗаданиеВнеОчереди. Оттуда фоново запускаются Исполнитель_Выполнение, которые пытаются ВзятьЗаданиеВРаботу. Т.е. ВзятьЗаданиеВРаботу запускается из другого сеанса, когда запись в мзЗадания ещё заблокирована в основном потоке (транзакция не завершилась).

Попробую завтра тест набросать.

[berezdetsky]

ТестМенеджерЗаданий.zip

С днём рождения! :)

[wizi4d]

Спасибо за поздравление!

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

Я сделал следующий тест:

Для Сч = 0 По КоличествоЗаданий Цикл
        ОбработкаПрерыванияПользователя();
        мзЗадания.ДобавитьЗаданиеВнеОчереди("Тестирование.ЗаданиеФеникс", Новый Структура("ИзОчереди", Ложь));
    КонецЦикла;

Не рекомендую число больше 500 туда вписывать, проц перегреется :) Задания сами себя будут ставить до бесконечности.

Я это использовал для проверки на блокировки как раз. На моей текущей машине (i5 4 ядра) при ~200 записей в секунду узким местом выступает как раз проц и запуск фоновых. При этом ЖР в плане ошибок абсолютно чистый.

[berezdetsky]

Как минимум, ожидается что задание не зависнет. Напомню, там версия 1.4.3. :)
Как максимум - что таймаута вообще не будет. Типа:
Если ТранзакцияАктивна() Тогда
    ДобавитьЗадание(...); // не запускать вне очереди
КонецЕсли;

[wizi4d]

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

[berezdetsky]

Не фотошоп :)

[wizi4d]

Попробуй у себя предложенный мной тест провести. Выставь 2к исполнителей и 300-400 стартовых заданий и оставь на пару десятков минут. Интересно какой результат будет.
Сервер 1С локальный лучше использовать, чтобы никому не мешать. Нагрузит процы по полной, на машине что-то параллельное точно нельзя будет делать.

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

[berezdetsky]

В таком сценарии можно получить блокировку только если один из потоков добьётся эскалации блокировок. Моя проблема показана в моём тесте.

Конечно, код можно переписать. Но посмотри на это с другой колокольни. Есть рабочий код, запускающий фоновые задания. Для повышения надёжности переписываем запуск через менеджер. Получаем ошибку на ровном месте.

Сейчас, чтобы сразу написать правильно, нужно понимать, как там всё устроено. По хорошему, надо бы исправить или код или документацию.

Upd. На твоём тесте ошибок не возникает.

[wizi4d]

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

Есть идеи, какие изменения нужно внести в документацию?

[berezdetsky]

Нету.

Есть идея по изменению кода - выше. Там обратная совместимость пострадает, но ожиданий на блокировках не будет.

[wizi4d]

Вынести из таблицы заданий отметки времени и состояния в отдельную таблицу
истории состояний? Вот только консистентность пострадает, откат транзакции,
а фоновое что-то делает...
Ср, 20 апр. 2016 г. в 11:17, berezdetsky notifications@github.com:

Нету.

Есть идея по изменению кода - выше. Там обратная совместимость пострадает,
но ожиданий на блокировках не будет.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#16 (comment)

[berezdetsky]

Нет. Добавить в ДобавитьЗаданиеВнеОчереди проверку наличия активной транзакции, и при её наличии отправлять вызов в ДобавитьЗадание.

[wizi4d]

В случае долгой транзакции и если подошло время стартовать менеджеру ошибка
все равно возникнет, просто количество станет поменьше.
Ср, 20 апр. 2016 г. в 11:31, berezdetsky notifications@github.com:

Нет. Добавить в ДобавитьЗаданиеВнеОчереди проверку наличия активной
транзакции, и при её наличии отправлять вызов в ДобавитьЗадание.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#16 (comment)

[berezdetsky]

Так запрос эти задания не увидит. Или сам запрос будет ждать на блокировке диапазона индекса? Надо будет проверить..