- Регистрация
- 23.12.2014
- Сообщения
- 14 453
- Благодарностей
- 5 473
- Баллы
- 113
Обращаем Ваше внимание на то, что данный пользователь заблокирован.
Не рекомендуем проводить с Mikhail B. какие-либо сделки.
Не понимаю где ошибка?
Выполнение действия ImageProcessing Недопустимый параметр/Ошибка при получении изображения
- Автор темы Mikhail B.
- Дата начала
- Регистрация
- 23.12.2014
- Сообщения
- 14 453
- Благодарностей
- 5 473
- Баллы
- 113
Обращаем Ваше внимание на то, что данный пользователь заблокирован.
Не рекомендуем проводить с Mikhail B. какие-либо сделки.
Был какой то косяк инстанса, сейчас нормально.
- Регистрация
- 23.12.2014
- Сообщения
- 14 453
- Благодарностей
- 5 473
- Баллы
- 113
Обращаем Ваше внимание на то, что данный пользователь заблокирован.
Не рекомендуем проводить с Mikhail B. какие-либо сделки.
Бывают такие заскоки но очкнь редко.
За 2 месяца использования Zenno подобных ошибок не видел. В последние 3-4 дня стали выскакивать постоянно!
Замечено, что при возникновении такой ошибки все потоки в шаблоне сильно замедляются, из-за чего ломается вся логика работы шаблонов, т.к. нужно уложиться в конкретное временное окно. Время выполнения шаблона в многопоточном режиме увеличивается с 280-290 секунд до 280-700.
Сами шаблоны не правил, сервера где работают Zenn'ы те же. Софт тот же.
В зеннобоксе такие ошибки возникают гораздо чаще!
Решение вопроса - не использовать кубик сохранения изображения. Но все-таки он нужен.
Замечено, что при возникновении такой ошибки все потоки в шаблоне сильно замедляются, из-за чего ломается вся логика работы шаблонов, т.к. нужно уложиться в конкретное временное окно. Время выполнения шаблона в многопоточном режиме увеличивается с 280-290 секунд до 280-700.
Сами шаблоны не правил, сервера где работают Zenn'ы те же. Софт тот же.
В зеннобоксе такие ошибки возникают гораздо чаще!
Решение вопроса - не использовать кубик сохранения изображения. Но все-таки он нужен.
- Регистрация
- 06.11.2018
- Сообщения
- 11 789
- Благодарностей
- 5 727
- Баллы
- 113
по моим наблюдениям проблемы с этим кубиком (а так же с любыми обращениями к браузеру ) как раз и начинаются с проблем в инстансе. если инстанс упал то любое обращение к его методам приведет к зависанию потока и отвиснет он только через N количество минут которое указано тут
вся проблема в том что этот таймаут не имеет свойства генерировать BadEnd и по этому команда завершается и тут же по ходу логики влетает как ни в чем не бывало в следующую операцию по работе с браузером. и висеть может очень долго. жрет при этом безбожно память и процессор. если бы был BadEnd на этот тайм аут то можно легко выводить шаблон на выход без обращений к браузеру и ничего не зависало бы и не накапливалось в памяти. Но увы и ах, этого нет. а инстансы падают очень часто. вот например 10 потоков и 3 упавших инстанса за 1 час.
решение может быть только одно. долбать разработчиков на введение BadEnd на тайм аут выполнения команды в инстансе, потому как в арсенале зенки нет ни одной команды которая должна выполняться больше 1 минуты.
вся проблема в том что этот таймаут не имеет свойства генерировать BadEnd и по этому команда завершается и тут же по ходу логики влетает как ни в чем не бывало в следующую операцию по работе с браузером. и висеть может очень долго. жрет при этом безбожно память и процессор. если бы был BadEnd на этот тайм аут то можно легко выводить шаблон на выход без обращений к браузеру и ничего не зависало бы и не накапливалось в памяти. Но увы и ах, этого нет. а инстансы падают очень часто. вот например 10 потоков и 3 упавших инстанса за 1 час.
решение может быть только одно. долбать разработчиков на введение BadEnd на тайм аут выполнения команды в инстансе, потому как в арсенале зенки нет ни одной команды которая должна выполняться больше 1 минуты.
Присоединяюсь к вашему пожеланию! Как можно "задолбать" разработчиков? BadEnd по таймауту на выполнение команд в инстансе просто необходим!
Шаблон рассчитанный на работу строго в 5 минут, с массой проверок после каждого чиха может спокойно уйти в небытие на три (!!!) часа! И при этом нет инструмента выйти вовремя...
Я эту ситуацию решил "извратом", но очень дорого.
Поставил сервер управления шаблонами. Шаблоны по api коннектятся и получают для себя задачи, а серверный скрипт разруливает всю логику на php.
Чтобы инстансы не падали, каждый шаблон запущен на физически отдельном сервере (!!!) и не более 20 потоков на каждом. Нагрузка на проц любого шаблона - не более 20%, свободной памяти - до дури. Шаблон на одном сервере только один!!! Если будет второй - потоки начнут уходить в спячку.
Правило: Один сервер = один шаблон, один шаблон = не более 20 потоков. И это сносно работает.
Пока серверов 8 и еще можно терпеть шум от их работы, но по плану их 80! Если разработчики не дадут контроль над таймаутом - расплавятся провода...
- Регистрация
- 06.11.2018
- Сообщения
- 11 789
- Благодарностей
- 5 727
- Баллы
- 113
Им нужны шаблоны для воспроизведения проблемы.... можно подумать у них браузерные шаблоны работают идеально. я им пару раз предлагал доступ на свой сервер, но они молча игнорят такие предложения.
а зря. у меня они бы в реальном времени словили все закидоны браузерных шаблонов. а передать им свои шаблоны нет возможности , потому как я их активно дорабатываю.
вот думаю может их трасерами закидать ?
ну а что остается ?
- Регистрация
- 06.11.2018
- Сообщения
- 11 789
- Благодарностей
- 5 727
- Баллы
- 113
написано же .... недопустимые знаки
вот что в переменной scrinim находиться ? наверняка что то запретное
Bot
Новичок
- Регистрация
- 18.11.2014
- Сообщения
- 3
- Благодарностей
- 0
- Баллы
- 1
Как бы там ничего запретного не было .. Но я просто не так юзал - для моей задачи пришлось каждый раз список поднимать и тогда имя файла записывалось норм без ошибок .написано же .... недопустимые знаки
вот что в переменной scrinim находиться ? наверняка что то запретное
Oleg-KC
Client
- Регистрация
- 17.02.2020
- Сообщения
- 174
- Благодарностей
- 58
- Баллы
- 28
Такая же история была сегодня, решил сменой со стандартного метода Http на альтернатиивный