The remote server returned an error: (413) Request Entity Too Large.

Добрый день!

Очередное открытие ограничений.
Одним запросом пытаюсь заменить признак "скоропорт" на "нескоропорт" для 2700+ позиций с помощью инвентаризации.
Другими словами, нужно каждую скоропорт продукцию списать и оприходовать аналогичный, но без признака скоропорт.
Возвращается ошибка:
The remote server returned an error: (413) Request Entity Too Large. Ошибка не Меркурий.

Далее пробую 1000 записей обработать и ... уже более 14 часов запрос в статусе IN_PROCESS.
Еще бы знать отработает он как надо или упадет/уже упал в ошибки, но ответа не вернул.

К слову, запросы и ответы храню как XML в MS SQL, запрос сохранился, но открыть его не представляется возможным (

Подскажите пожалуйста. У кого какой опыт по проведению масштабных процедур.

Павел.

Запрос в том же статусе и есть подозрение, что он действительно выполняется, так как стали увеличиваться остатки!

miskevich wrote:Запрос в том же статусе и есть подозрение, что он действительно выполняется, так как стали увеличиваться остатки!

Ужас! Т.е., обработка запроса не завершена, а Вы видите изменения остатков? Чтение грязных данных? А если потом произойдет ошибка и запрос так и не завершится нормально?

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

Конечно прецедент "чтения грязных данных" довольно мрачно рисует будущее. Но ведь и блокировать остатки нельзя.

miskevich wrote:Процесс до сих пор не поменял статус. И если мне не изменяет память, то через несколько дней просто перестанет возвращать статус.

Что в данном случае означает, что процесс издох, не оставив предсмертной записки. Что он там сделал, не сделал?

miskevich wrote:
Все позиции склада с признаком скоропорт заменены на нескоропорт мелкими запросами по 100 записей, а первоначальный запрос в 1000 записей сейчас может только дублировать остатки (хотя бы не уменьшать), которые мы уберем при следующей инвентаризации "протухших" остатков.
Конечно прецедент "чтения грязных данных" довольно мрачно рисует будущее. Но ведь и блокировать остатки нельзя.

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

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

Вывод, как в общем то и всегда, все манипуляции с остатками, в том числе инвентаризация, производятся при остановленных отгрузках и процессах производства

miskevich wrote:Вывод, как в общем то и всегда, все манипуляции с остатками, в том числе инвентаризация, производятся при остановленных отгрузках и процессах производства

"Производятся" (системой Меркурий) или "следует производить"?

конечно следует производить и контроль должен осуществляться заинтересованными лицами, то есть нами, а никак не Меркурий.

miskevich wrote:Добрый день!

Очередное открытие ограничений.
Одним запросом пытаюсь заменить признак "скоропорт" на "нескоропорт" для 2700+ позиций с помощью инвентаризации.
Другими словами, нужно каждую скоропорт продукцию списать и оприходовать аналогичный, но без признака скоропорт.
Возвращается ошибка:
The remote server returned an error: (413) Request Entity Too Large. Ошибка не Меркурий.

Далее пробую 1000 записей обработать и ... уже более 14 часов запрос в статусе IN_PROCESS.
Еще бы знать отработает он как надо или упадет/уже упал в ошибки, но ответа не вернул.

К слову, запросы и ответы храню как XML в MS SQL, запрос сохранился, но открыть его не представляется возможным (

Подскажите пожалуйста. У кого какой опыт по проведению масштабных процедур.

Павел.

Ну просто необходимо делать по номенклатурно 2700 Инвентаризация по 1-ой позиции !! И будет вам счастье !!!

Вот совет так совет, благодарю. В следующий раз на заправке попробую не полный бак, а по литру 80 литров залить )

miskevich wrote:Вот совет так совет, благодарю. В следующий раз на заправке попробую не полный бак, а по литру 80 литров залить )

Какой "полный бак", XXI век на дворе, давно пора в Теслу по кулону заряд заливать!

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

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

> The remote server returned an error: (413) Request Entity Too Large.
> Ошибка не Меркурий
Да, это ошибка возвращается протоколом HTTP(S) и означает, что вы передаёте слишком большой объём данных.

> Далее пробую 1000 записей обработать и ... уже более 14 часов запрос в статусе IN_PROCESS.
> Еще бы знать отработает он как надо или упадет/уже упал в ошибки, но ответа не вернул."

1000 записей также довольно много для запроса. Мы рекомендуем проверить, изменены ли записи журнала, по которым проводилась инвентаризация. Данный запрос уже не перейдёт в статус COMPLETED, поэтому больше опрашивать его не требуется. В дальнейшем лучше уменьшить количество записей в рамках одной операции и увеличить количество самих операций.

С уважением,
Служба технической поддержки ВетИС.API
8 (4922) 52-99-29

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

В дальнейшем лучше уменьшить количество записей в рамках одной операции и увеличить количество самих операций.

С уважением,
Служба технической поддержки ВетИС.API
8 (4922) 52-99-29

Вот за такой ответ работников техподдержки следует расстреливать ржавыми гвоздями. "Лучше уменьшить" до каких значений? Ну, давайте, не стыдитесь, назовите точно то число записей в одной операции, которое сервер сможет обработать. Иначе это не ТЕХ-поддержка, а гадалки. "Ну, тут бы лучше уменьшить, а там - увеличить. Наверное. Нам так кажется."

Полностью согласен. Но вчера 15.05.2018 на конференции Ашан Власов Н.А. сказал, что техподдержка у них такая (численность), какую они могут себе позволить.
Также сообщил, что в ближайшее время сторонней компанией будет реализован публичный мониторинг доступности ФГИС Меркурий. Ждем.