Application с "вечным" статусом IN_PROCESS

Добрый день!

Коллеги, как вы уже знаете, с 12 на 13 мая 2018 было проведено нагрузочное тестирование ФГИС Меркурий.
Как результат появились заявки с "вечным статусом" IN_PROCESS(оформление производственной и транспортной транзакций). Проверка проводилась спустя более 12 часов с первоначальной отправки запросов.
Подобный вопрос уже был мной озвучен http://vetrf.ru/vetrf-forum/posts/list/7899.page Но тут понятен чрезмерный объем желаний.

Вопрос:
Какой период времени опроса заявки считать достаточным, чтобы сделать вывод о "зависании" и повторном запросе?
Предложение/просьба
Система ФГИС Меркурий должна реализовать "сборщик мусора", который бы отправлял в статус REJECTED подобные запросы с вечным IN_PROCESS.

Примеры запросов ApplicationId:
de54b6f1-cbe3-405c-aa0e-08ee6933ead3
06b79f14-c3ee-4af7-a361-bd23665b1422
1b3f0696-c926-4b78-8263-7a4de5c9b962
7e7890d0-f324-4049-a382-8c93b6b35139
80e60b69-fbdd-471e-8ee5-f631480d1df1
22130753-4645-488e-ab5a-4a767d69d88f
c8ef869e-dbae-49a1-808a-1f75734f73e6
1005300e-ee35-4e36-9cdd-abd936d1dda6

Письмо в техподдержку api@vetrf.ru написано Пн 14/05/2018 12:02

Павел.

Твои запросы ни кто не увидет, так как требуется указать ХС и апи кей, логин и пароль.

Это информация для техподдержки Меркурий

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

Vladimir2017 wrote:В автоматизации надо делать проверку - несколько запросов с небольшим интервалом, что-нибуть типа 10 через 3. Если через 30 сек. все еще приходит in_process кидаем заявку в туже категорию что и rejected. Это не первый случай, кстати, у меня пару суток висели такие заявки без движения.

Согласен с Вами. Конечно важно оперативно отправить ночную отгрузку, но и задержка в 30 секунд это много.
Возникает второй вопрос, не обработается ли висящая заявка позднее ... Лишнюю транзакцию аннулируем, но пока вычисляем товара не хватит для других ТТН, разрыв остатков и т.д.
Если додумать тему до маркировки GS-128, то по Меркурий клиенту уйдет несколько коробок с одинаковым порядковым номером короба в производственной партии, чего быть в идеале не может.

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

По данному вопросу нужна официальные разъяснения ведомства, как и по работе без интернета/Меркурия/электричества и т.д.

miskevich wrote: Возникает второй вопрос, не обработается ли висящая заявка позднее ...

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

По данному вопросу нужна официальные разъяснения ведомства, как и по работе без интернета/Меркурия/электричества и т.д.

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

ответ техподдержки:

"Здравствуйте!

Обращаем ваше внимание, что в ночь с 12.05.2018 на 13.05.2018 проводилось нагрузочное тестирование рабочего сервера Меркурия. Об этом сообщалось на официальном сайте Россельхознадзора 8 мая 2018 года: http://www.fsvps.ru/fsvps/news/26415.html. Заявки в статусе IN_PROCESS опрашивать не рекомендуется, поскольку они уже не будут выполнены и вскоре станут просто недоступны.
Также мы рекомендуем следить за новостями, касающимися системы Меркурий на сайте Россельхознадзора, поскольку мы информируем пользователей об обновлениях системы и плановых работах.

> Вопрос:
> Какой период времени опроса заявки считать достаточным, чтобы сделать вывод о "зависании" и повторном запросе?
Согласно Приказу №589 МСХ РФ ветеринарный сертификат должен быть оформлен в течение суток с момента подачи заявки. По факту время, конечно, меньше. Если заявка находится в статусе IN_PROCESS более 15 минут - это повод для обращения в техническую поддержку."

сделал выход из цикла ожидания ответа после 300 запросов, в цикле задержка 1 секунда, плюс время на ожидание ответа, т.е. жду как бы больше 5 минут. За ночь отправляется 15к ВСД, правда есть у нас кое-какая хитрость (отправляем документы в несколько потоков). Так как ВСД со статусом IN_PROCESS всё-таки в какой-то момент появляются в Меркурии, транспортные и производственные ВСД дублируются, такая картина наблюдалась ещё до 12.05.2018, разработчики и поддержка разводят руками, даже не удивился ответу поддержки.

hawksib wrote: (отправляем документы в несколько потоков)

Первые попытки многопоточности привели к, если память не подводит, APLM0012.

Но в целом очень здравый подход. Чуть добавлю, нужно опрашивать заявку с паузой в 1 секунду 10-100 раз, потом, если IN_PROCESS, выделять опрос в отдельный поток, а основной процесс пойдет дальше. При массовом зависании все равно получим APLM0012.

hawksib wrote:сделал выход из цикла ожидания ответа после 300 запросов, в цикле задержка 1 секунда, плюс время на ожидание ответа, т.е. жду как бы больше 5 минут. За ночь отправляется 15к ВСД, правда есть у нас кое-какая хитрость (отправляем документы в несколько потоков). Так как ВСД со статусом IN_PROCESS всё-таки в какой-то момент появляются в Меркурии, транспортные и производственные ВСД дублируются, такая картина наблюдалась ещё до 12.05.2018, разработчики и поддержка разводят руками, даже не удивился ответу поддержки.

При дублях производственных всд у вас также и дублируется списание сырья?

ilart1991 wrote:
При дублях производственных всд у вас также и дублируется списание сырья?

конечно

hawksib wrote:

ilart1991 wrote:
При дублях производственных всд у вас также и дублируется списание сырья?

конечно

каким образом вышли из положения? Мы вот неснижаемый остаток программно задали, чтобы в 1с ниже указанного кол-ва не списывалось сырье. Опять же, из-за рассинхрона остатков 1с и мерка в результате этих задвоений.

ilart1991 wrote:

hawksib wrote:

ilart1991 wrote:
При дублях производственных всд у вас также и дублируется списание сырья?

конечно

каким образом вышли из положения? Мы вот неснижаемый остаток программно задали, чтобы в 1с ниже указанного кол-ва не списывалось сырье. Опять же, из-за рассинхрона остатков 1с и мерка в результате этих задвоений.

пока реализовали подгон остатка в 1с к остатку в Меркурии, далее планируем отправлять инвентаризацию, по неверно списанным партиям

hawksib wrote:

ilart1991 wrote:

hawksib wrote:

ilart1991 wrote:
При дублях производственных всд у вас также и дублируется списание сырья?

конечно

каким образом вышли из положения? Мы вот неснижаемый остаток программно задали, чтобы в 1с ниже указанного кол-ва не списывалось сырье. Опять же, из-за рассинхрона остатков 1с и мерка в результате этих задвоений.

пока реализовали подгон остатка в 1с к остатку в Меркурии, далее планируем отправлять инвентаризацию, по неверно списанным партиям

много записей журнала сырья в 1с? или все в один котел и далее синхронизация с мерком?

такое чувство, что сейчас идет опять какой-то тест, при тестировании ошибку "APLM0012": An unexpected error has occurred while invoking target service operation., намного реже ловил, кто-нибудь ещё наблюдает проблемы сейчас? IN_PROCESS вроде не зависают запросы