Ловим зависшие инстансы

[Phoenix78]

Давно хотел написать эту статейку. Оставлю тут, чтоб была

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

Немного теории. Когда Зеннопостер запускает шаблон в работу, он создает в памяти уникальный изолированный процесс, а так же все объектные структуры для этого процесса. Один из самых важных объектов это наш браузер.
Обращаемся мы к нему как instance . И когда зависает шаблон, говорят инстанс завис или упал или закрашился. Все это верно по отношению к instance , но сам шаблон не завис и не рухнул. Другие объекты продолжают существовать и код продолжает выполняться. Но обращение из шаблона к упавшему браузеру вызывает коллизии и выполнение кода замирает на этой команде (это относиться как к кубикам, так и к коду на C#). В далеком прошлом это приводило к абсолютному зависону шаблона, вот прям намертво. Тогда разработчики внедрили временный костыль - таймаут выполнения команды в инстансе (находиться в настройках зеннопостера), которая принудительно прерывала слишком долгую команду. Сейчас можно встретить заявления, что данная настройка является пережитком прошлого и уже ни на что не влияет. Но это больше маркетинговый ход. Все мы знаем, что инстансы продолжают падать и данная настройка остается важной до сих пор. Вроде все хорошо, даже инструмент есть для снятия зависших команд, НО срабатывание данного таймаута не носит критического характера и не генерируется абсолютно никаких исключений. Выполнение шаблона продолжает выполняться как ни в чем не бывало. Разработчиков можно понять, им прогу продавать надо, а тут будут такие ошибки сыпаться как из рога изобилия. Так вот и получается, что даже при таймауте в 1 минуту выполнение логики шаблона приходит (а если браузер уже упал, то приползает) к какому нибудь циклу, где опрашивается элемент на странице с целью ожидания его появления в течении 12-20 секунд. Нам просто гарантированно выполнение данного цикла минут 20. а потом логика шаблона может уйти на еще какие нибудь действия с элементами браузера. И никаких ошибок в логе. Естественно не все потоки разом вот так зависают, но они накапливаются и получаем кучу "работающих" потоков, которые ничего не делают. А ошибок нет.
Причины падения браузера известны только разработчикам, а иногда даже они не знают что происходит в процессе. Конечно работы по улучшению стабильности идут , но от падения браузера никто не застрахован и в будущем скорее всего тоже.
Нам с вами от этого не легче и поэтому давайте разбираться что можно сделать в этой непростой ситуации.

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

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

Как выйти из шаблона ?
Механизм выхода универсален. Используем рабочий функционал Зеннопостера. Выход через BadEnd. С единственный условием, после BadEnd не должно быть никакого обращения к браузеру. всякие скриншоты, сохранение профиля ,закрытия вкладок , всего этого быть не должно. Запись в лог, в базу данных можно. Таким образом шаблон свободно выйдет, без лишних пауз. И никаких зацикливаний через BadEnd, так как данный механизм срабатывает только один раз.

И как попасть на BadEnd ?
Для попадания на BadEnd надо что бы было сгенерировано необработанное исключение. Другими словами выход из кубика по красному выходу, не занятой линией.
И вот тут надо рассказать о правильном построении шаблона, с учетом отлова зависшего браузера. Получается, что для аварийного выхода нам надо иметь свободный красный выход, так же для реализации логики шаблона нам надо иметь 2 выхода. итого 3 выхода нужно. а имеем только 2. Выход в использовании 2-х кубиков. в первом кубике должна выполняться "Рисковая операция", это все что связано с работой браузера, а во втором кубике будет "Безрисковая логика". Первый кубик будет возвращать какой нибудь результат в переменную или генерировать аварийное исключение , а второй кубик будет проверять результат работы первого кубика и принимать решение куда выходить, на зеленую или на красную.

Как идентифицировать падение браузера ?
Есть пара способов, но для уверенности надо использовать все проверки, так как по отдельности могут и не сработать.
Проверяем активную вкладку на наличие. Именно активную, так как ранее сформированная может уже и закрытой быть. instance.ActiveTab.IsNull и instance.ActiveTab.IsVoid
Проверка времени выполнения команд. Засекаем время до выполнения и после. Считаем разницу и если команда выполнялась долго формируем исключение. метод по аналогии с внедренным разработчиками, только с аварийным выходом.
ну а куда деваться если разработчики не хотят внедрять аврал в свой метод ? правильно , сделаем сами
и да, для команд выполняемых в цикле надо проверять внешние прерывания, что бы шаблон можно было прервать в любую секунду.

// засекаем время
DateTime now = DateTime.Now;
// выполняем рисковую команду с браузером
instance.ActiveTab.FindElementByXPath("",0);
// считаем сколько времени выполнялась команда
TimeSpan Delta_Time = DateTime.Now-now;
int Time_Difference                    =     Delta_Time.Milliseconds;
Time_Difference = Time_Difference +     Delta_Time.Seconds*1000;
Time_Difference = Time_Difference +     Delta_Time.Minutes*60*1000;
Time_Difference = Time_Difference +     Delta_Time.Hours*60*60*1000;
Time_Difference = Time_Difference +     Delta_Time.Days*24*60*60*1000;
// анализируем время
if ( Time_Difference > 60000 ) throw new Exception("Обнаружено замедление выполнения команды в инстансе, таймер = " + Time_Difference.ToString() );
// проверка вкладки на пустоту
if ( instance.ActiveTab.IsVoid || instance.ActiveTab.IsNull )     throw new Exception("Обнаружена пустая вкладка");
// выход по внешнему требованию
if(((ZennoLab.InterfacesLibrary.ProjectModel.Collections.IContextExt)project.Context).IsInterrupted) throw new Exception("Внешнее прерывание");
if(Global.Variables.IsProjectMaker && !Global.Variables.IsDebugMode)  throw new Exception("Внешнее прерывание");

да, одна команда превращается в кучу кода. читаемость кода резко падает. как выход все это можно запихнуть в общий код. как пример приведу переход по URL в общем коде
а в кубике C# она вызывается tab.NavigateWithCheck(url, DateTime.Now ,NavigateTimeout);

вот вроде все описал по своему видению этой проблемы.
и еще. на текущую дату вышла новая версия 5.40 (7.1.1.0) и в ней по предварительным тестам под движком хрома зависшие потоки снимаются и рестартятся мгновенно. что в совокупности с методом идентификации зависших потоков делает ее пригодной для работы 24/7

PS. Забыл упомянуть про кубик IF
Стандартный кубик IF работает не на C#, а на яваскрипт. И при возникновении проблем с браузером логично предположить, что код яваскрипта будет немного сбоить . Редко, но метко как говорят.
А проведенный стресс-тест показал, что при упавшем браузере кубик IF будет всегда выходить по красной. Поэтому для улучшения стабильности работы шаблона лучше полностью отказаться от кубика IF и использовать кубик C# с прописанной логикой на C#
Разработчики до сих пор уверяют, что кубик IF не глючный. Можно с ними согласиться , только в том случае когда все работает, но если надо ловить ситуации в условиях краха , этот инструмент не подходит.

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

 

[Astraport]

О, респект!
Надо изучить, проблема очень актуальная.

 

[Phoenix78]

Затестил вышедшую 7.1.1.0
Под движком хрома рестарт зависших потоков не мгновенный. занимает 4-6 минуты. Падают инстансы не часто, но за сутки довольно много набралось. Намертво ни один поток не завис, выход по таймауту спасает. Походу этот метод будет еще долго актуален, пока разработчики не поймают этот баг. Надеяться что они сами сделают диагностику упавшего инстанса не приходиться, поэтому решаем своими руками.
Под движком файрфокса у меня за сутки при 10 потоках , было обнаружено всего 6 упавших инстанса. один запуск шаблона работает около 20 минут. Можно сказать файрфокс стабилен , хоть и устарел уже.

 

[sociohacker]

Тема - всеми любимые зависоны шаблонов.

Здравствуйте и в этой теме!

Спасибо вам огромное за инфу! Дико удивляет, почему этой проблеме НЕ уделяется 99% внимания разработчиков, ибо без стабильной эффективной работы ЗП нет смысла в новых фишках же.

Если вас не затруднит, прошу ответить на пару вопросов касаемо написанного вами выше:
1)

после BadEnd не должно быть никакого обращения к браузеру. всякие скриншоты, сохранение профиля ,закрытия вкладок , всего этого быть не должно. Запись в лог, в базу данных можно.

можно ли писать строчку в .txt файл стандартным кубиком (операции со списком)? Шаб в начале работы дёргает строчку из .txt списка акков, а на good/bad энде — запихивает её обратно. Вот хочу понять, если использовать ваш способ отлавливания зависонов, можно ли эту строчку как-то возвращать обратно в список со 100% гарантией (чтобы не потерялись строчки акков)? Стандартный кубик сработает или надо на С# колбасить?

2)

надо проверять внешние прерывания, что бы шаблон можно было прервать в любую секунду

Правильно ли понимаю, что если поставить хотя бы 1 такой кубик с С# кодом

if(((ZennoLab.InterfacesLibrary.ProjectModel.Collections.IContextExt)project.Context).IsInterrupted) throw new Exception("Внешнее прерывание");

в проект (первым кубиком, например), то при прерывании шаблона через контекстное меню в самом ЗП, шаблон резко прервётся и пойдёт по BAD END, на каком бы этапе в этот момент он ни находился? То есть, даже в случае с рабочим инстансом — если прервём шаблон, то выведем его по BAD END и, таким образом, он успеет сделать запись строки акка обратно в список?

Если так, то это круто в любом случае, даже если нет проблем с инстансом!

3) немного не понял насчёт сравнения времени выполнения "рисковой команды". Нам надо засекать время перед каждым кубиком действия с браузером? И потом после кубика - получать текущее время и сравнивать с прошлым?

Видимо, я не понял просто принципа самого кубика с С# кодом...

Подозреваю, что в нём ведь уже есть всё сразу, то есть, мы через С# сначала засекаем время, затем делаем универсальную "рисковую операцию" — запрашиваем любой элемент на активной вкладке, а уже потом, если долго не можем его получить — то выходим по BAD END? Верно?

ИТОГО: можно кубик с этим кодом

// засекаем время
DateTime now = DateTime.Now;
// выполняем рисковую команду с браузером
instance.ActiveTab.FindElementByXPath("",0);
// считаем сколько времени выполнялась команда
TimeSpan Delta_Time = DateTime.Now-now;
int Time_Difference                    =     Delta_Time.Milliseconds;
Time_Difference = Time_Difference +     Delta_Time.Seconds*1000;
Time_Difference = Time_Difference +     Delta_Time.Minutes*60*1000;
Time_Difference = Time_Difference +     Delta_Time.Hours*60*60*1000;
Time_Difference = Time_Difference +     Delta_Time.Days*24*60*60*1000;
// анализируем время
if ( Time_Difference > 60000 ) throw new Exception("Обнаружено замедление выполнения команды в инстансе, таймер = " + Time_Difference.ToString() );
// проверка вкладки на пустоту
if ( instance.ActiveTab.IsVoid || instance.ActiveTab.IsNull )     throw new Exception("Обнаружена пустая вкладка");
// выход по внешнему требованию
if(((ZennoLab.InterfacesLibrary.ProjectModel.Collections.IContextExt)project.Context).IsInterrupted) throw new Exception("Внешнее прерывание");
if(Global.Variables.IsProjectMaker && !Global.Variables.IsDebugMode)  throw new Exception("Внешнее прерывание");

ставить ДО и ПОСЛЕ каждого обычного кубика в ПМ и тогда мы будем 100% подстрахованы от огромных потерь времени из-за ошибок браузера, верно?

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

Спасибо ещё раз за то, что делитесь наработками по этой проблеме. Вы мне тут реально спасаете положение этой инфой

P. S.: как думаете, может есть смысл ещё меньше таймаут выставить вот тут?

if ( Time_Difference > 60000 ) throw new Exception("Обнаружено замедление выполнения команды в инстансе, таймер = " + Time_Difference.ToString() );

Ведь если мы ищем любой элемент на странице, то он должен находиться очень быстро, за секунды. Значит, можно выставить тайм-аут в 20 сек - и будет норм? У меня всё равно всегда паузы стоят после перехода на URL по 15-20 секунд, так как иногда кубик перехода срабатывает сразу и уже отображается выполненным в ПМ, хотя по факту страничка ещё грузится.

 

[Phoenix78]

можно ли писать строчку в .txt файл стандартным кубиком (операции со списком)? Шаб в начале работы дёргает строчку из .txt списка акков, а на good/bad энде — запихивает её обратно. Вот хочу понять, если использовать ваш способ отлавливания зависонов, можно ли эту строчку как-то возвращать обратно в список со 100% гарантией (чтобы не потерялись строчки акков)? Стандартный кубик сработает или надо на С# колбасить?

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

Правильно ли понимаю, что если поставить хотя бы 1 такой кубик с С# кодом

if(((ZennoLab.InterfacesLibrary.ProjectModel.Collections.IContextExt)project.Context).IsInterrupted) throw new Exception("Внешнее прерывание");

в проект (первым кубиком, например), то при прерывании шаблона через контекстное меню в самом ЗП, шаблон резко прервётся и пойдёт по BAD END, на каком бы этапе в этот момент он ни находился? То есть, даже в случае с рабочим инстансом — если прервём шаблон, то выведем его по BAD END и, таким образом, он успеет сделать запись строки акка обратно в список?
Если так, то это круто в любом случае, даже если нет проблем с инстансом!

нет, это масло масляное. При прерывании проекта для шаблона выставляется флаг прекращения работы, который всегда проверяется системой при переходе между кубиками.
Эта строка нужна для теоретически долгих циклов именно внутри кода C# так как кроме программиста реализующего логику цикла , там никто не властен.
насчет сохранности записи выше написал.

3) немного не понял насчёт сравнения времени выполнения "рисковой команды". Нам надо засекать время перед каждым кубиком действия с браузером? И потом после кубика - получать текущее время и сравнивать с прошлым?

нет, я писал про команды аналоги на C# . все это должно происходить в коде C#, в кубике или в общем коде. Я использую кубики и графическую систему как логическое построение в целом. Потому что мне так удобно.
Например я кликнул по кнопке. Мне надо дождаться результата. Я пихаю код нахождения элемента и сам клик в первый кубик и проверяю результат во втором. дальше самое опасное, ожидание прогруза элемента.
В цикле с периодичностью 1 секунда происходит обращение к браузеру. И если он крашиться имеем непредвиденный долгий цикл. Выйти из цикла помогает как раз замер времени операции считывания из браузера. А сам кубик может долго выполняться, в этом нет ничего плохого. Именно по причине того что вот такой огород надо городить с каждой командой, я и писал что код становиться нечитабельным и очень большим. этот момент надо четко понимать. Выход конечно есть. Надо изучить как строить код в общем коде и тогда все опять сворачивается в удобочитаемый код в кубике C#. вот пример как у меня выглядит кубик ожидания элемента.

а вся работа делается в общем коде. ну там такие портянки....

ставить ДО и ПОСЛЕ каждого обычного кубика в ПМ и тогда мы будем 100% подстрахованы от огромных потерь времени из-за ошибок браузера, верно?

Нет, это проект превратиться в огромного нечитаемого монстра. Кубики оставим разработчикам. Это их вотчина. Как компромисс, самые опасные по потери времени надо перевести в C# , в основном это циклы ожидания появления элемента.

P. S.: как думаете, может есть смысл ещё меньше таймаут выставить вот тут?

if ( Time_Difference > 60000 ) throw new Exception("Обнаружено замедление выполнения команды в инстансе, таймер = " + Time_Difference.ToString() );

Ведь если мы ищем любой элемент на странице, то он должен находиться очень быстро, за секунды. Значит, можно выставить тайм-аут в 20 сек - и будет норм? У меня всё равно всегда паузы стоят после перехода на URL по 15-20 секунд, так как иногда кубик перехода срабатывает сразу и уже отображается выполненным в ПМ, хотя по факту страничка ещё грузится.

Это аварийный таймер. Я себе 40 секунд выставил. Но по наблюдениям если происходит аврал то замедление будет от 50-60 секунд. зависит от этой настройки

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

 

[sociohacker]

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


нет, это масло масляное. При прерывании проекта для шаблона выставляется флаг прекращения работы, который всегда проверяется системой при переходе между кубиками.
Эта строка нужна для теоретически долгих циклов именно внутри кода C# так как кроме программиста реализующего логику цикла , там никто не властен.
насчет сохранности записи выше написал.

нет, я писал про команды аналоги на C# . все это должно происходить в коде C#, в кубике или в общем коде. Я использую кубики и графическую систему как логическое построение в целом. Потому что мне так удобно.
Например я кликнул по кнопке. Мне надо дождаться результата. Я пихаю код нахождения элемента и сам клик в первый кубик и проверяю результат во втором. дальше самое опасное, ожидание прогруза элемента.
В цикле с периодичностью 1 секунда происходит обращение к браузеру. И если он крашиться имеем непредвиденный долгий цикл. Выйти из цикла помогает как раз замер времени операции считывания из браузера. А сам кубик может долго выполняться, в этом нет ничего плохого. Именно по причине того что вот такой огород надо городить с каждой командой, я и писал что код становиться нечитабельным и очень большим. этот момент надо четко понимать. Выход конечно есть. Надо изучить как строить код в общем коде и тогда все опять сворачивается в удобочитаемый код в кубике C#. вот пример как у меня выглядит кубик ожидания элемента.
Посмотреть вложение 49652

а вся работа делается в общем коде. ну там такие портянки....


Нет, это проект превратиться в огромного нечитаемого монстра. Кубики оставим разработчикам. Это их вотчина. Как компромисс, самые опасные по потери времени надо перевести в C# , в основном это циклы ожидания появления элемента.


Это аварийный таймер. Я себе 40 секунд выставил. Но по наблюдениям если происходит аврал то замедление будет от 50-60 секунд. зависит от этой настройки
Посмотреть вложение 49653

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

Спасибо за разъяснения

Дело в том, что я не шарю в С#, только по мелочам. В моём случае нужна затычка от падений/зависаний инстанса при работе с обычными кубиками ЗП. Вот я и думаю, как лучше реализовать эту затычку в формате таких же кубиков с каким-то детектирующим падения/зависания С# кодом.

Как понимаю, если инстанс падает, то происходит ненужное и бессмысленное ожидание, равное продолжительности этого самого "Таймаута выполнения команды в инстансе" — такое происходит при каждом действии, имеющем отношение к браузеру, верно? И весь гемор в том, что невозможность выполнить это самое действие НЕ выводит шаблон по BAD END, ибо инстанс тупо не пашет и, следовательно, даже команда "найти элемент на странице" — НЕ выполнится с ошибкой. Получается, шаблон продолжает пытаться выполнять команды и занимает поток (и всё это тщетно, т. к. инстанс не пашет), правильно я понял?

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

 

[Oleg1987]

да, одна команда превращается в кучу кода. читаемость кода резко падает. как выход все это можно запихнуть в общий код. как пример приведу переход по URL в общем коде
а в кубике C# она вызывается tab.NavigateWithCheck(url, DateTime.Now ,NavigateTimeout);

Лучше сделать ддлку врапер, в ней обвертки для нужных методов в виде асинхронных функций. И внутри метода уже отщитывать время выполнения таски. Макс. время задавать опционально, чтоб можно было задать глобально для всего проекта либо в каждой функции отдельно в виде параметра.

 

[Phoenix78]

Лучше сделать ддлку врапер, в ней обвертки для нужных методов в виде асинхронных функций. И внутри метода уже отщитывать время выполнения таски. Макс. время задавать опционально, чтоб можно было задать глобально для всего проекта либо в каждой функции отдельно в виде параметра.

когда нибудь и до этого дойдет каждый на своем уровне развития.

 

[Phoenix78]

Спасибо за разъяснения

Дело в том, что я не шарю в С#, только по мелочам. В моём случае нужна затычка от падений/зависаний инстанса при работе с обычными кубиками ЗП. Вот я и думаю, как лучше реализовать эту затычку в формате таких же кубиков с каким-то детектирующим падения/зависания С# кодом.

Как понимаю, если инстанс падает, то происходит ненужное и бессмысленное ожидание, равное продолжительности этого самого "Таймаута выполнения команды в инстансе" — такое происходит при каждом действии, имеющем отношение к браузеру, верно? И весь гемор в том, что невозможность выполнить это самое действие НЕ выводит шаблон по BAD END, ибо инстанс тупо не пашет и, следовательно, даже команда "найти элемент на странице" — НЕ выполнится с ошибкой. Получается, шаблон продолжает пытаться выполнять команды и занимает поток (и всё это тщетно, т. к. инстанс не пашет), правильно я понял?

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

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

 

[sociohacker]

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

Понял, спасибо.

Я заметил странную штуку: проект относительно нормально работает при 30 потоках, а вот при поднятии до 40-50 - всё зависает напрочь. Вообще то есть. Как-то могут инстансы начинать тупить, только когда их много?
Ресурсы позволяют в 60-100 браузерных потоков работать, то есть не в этом причина, по идее.

У вас такое было?

 

[Phoenix78]

Понял, спасибо.

Я заметил странную штуку: проект относительно нормально работает при 30 потоках, а вот при поднятии до 40-50 - всё зависает напрочь. Вообще то есть. Как-то могут инстансы начинать тупить, только когда их много?
Ресурсы позволяют в 60-100 браузерных потоков работать, то есть не в этом причина, по идее.

У вас такое было?

всякое было. гулялка например умудрялась забредать на сайты с майнерами. даже 5-10 потоков просто вешали сервер. прикрутил блокировку нежелательных скриптов, отпустило.
Из последних закидонов, так это фул эмуляция мыши под хромом. толи фул скролл то ли фул движение , не знаю точно. просто вешали ту же гулялку и вылетали шабы по таймауту описанному в этом топике. убрал полностью фулэмуляцию из шаблона и уже 2-е суток ни разу не вылетел и не завис.

 

[sociohacker]

всякое было. гулялка например умудрялась забредать на сайты с майнерами. даже 5-10 потоков просто вешали сервер. прикрутил блокировку нежелательных скриптов, отпустило.
Из последних закидонов, так это фул эмуляция мыши под хромом. толи фул скролл то ли фул движение , не знаю точно. просто вешали ту же гулялку и вылетали шабы по таймауту описанному в этом топике. убрал полностью фулэмуляцию из шаблона и уже 2-е суток ни разу не вылетел и не завис.

Про майнеров - жесть, конечно

Слушайте, сорри заранее, если я задолбал... Но можно ли этот проверочный кубик С# ставить уже ПОСЛЕ Bad End? Хочу так: ЕСЛИ после наступления Bad End браузер работает, то сохраняем профиль. Если НЕ работает, то просто пишем в текстовый файлик.

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

 

[Phoenix78]

Про майнеров - жесть, конечно

Слушайте, сорри заранее, если я задолбал... Но можно ли этот проверочный кубик С# ставить уже ПОСЛЕ Bad End? Хочу так: ЕСЛИ после наступления Bad End браузер работает, то сохраняем профиль. Если НЕ работает, то просто пишем в текстовый файлик.

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

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

 

[sociohacker]

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

Спасибо. Типа вот так?

if ( Time_Difference > 60000 ) 
{throw new Exception("Обнаружено замедление выполнения команды в инстансе, таймер = " + Time_Difference.ToString() )
project.Variables["instance_fail"].Value = 1};

if ( instance.ActiveTab.IsVoid || instance.ActiveTab.IsNull )
{throw new Exception("Обнаружена пустая вкладка")
project.Variables["instance_fail"].Value = 1};

 

[Phoenix78]

Спасибо. Типа вот так?

if ( Time_Difference > 60000 )
{throw new Exception("Обнаружено замедление выполнения команды в инстансе, таймер = " + Time_Difference.ToString() )
project.Variables["instance_fail"].Value = 1};

if ( instance.ActiveTab.IsVoid || instance.ActiveTab.IsNull )
{throw new Exception("Обнаружена пустая вкладка")
project.Variables["instance_fail"].Value = 1};

if ( instance.ActiveTab.IsVoid || instance.ActiveTab.IsNull )
{
    project.Variables["instance_fail"].Value = "1";
    throw new Exception("Обнаружена пустая вкладка");
}
// замер времени
DateTime now = DateTime.Now;
string test = instance.ActiveTab.Name;    // или свою команду работающую с браузером
TimeSpan Delta_Time = DateTime.Now-now;
double Time_Difference = Delta_Time.TotalMilliseconds;

if ( Time_Difference > 60000 )
{
    project.Variables["instance_fail"].Value = "1";
    throw new Exception("Обнаружено замедление выполнения команды в инстансе" );
}

 

[Spelin]

всякое было. гулялка например умудрялась забредать на сайты с майнерами. даже 5-10 потоков просто вешали сервер. прикрутил блокировку нежелательных скриптов, отпустило.
Из последних закидонов, так это фул эмуляция мыши под хромом. толи фул скролл то ли фул движение , не знаю точно. просто вешали ту же гулялку и вылетали шабы по таймауту описанному в этом топике. убрал полностью фулэмуляцию из шаблона и уже 2-е суток ни разу не вылетел и не завис.

Отключил галку в настройки шаба или полностью убрал методы эмуляции full ?
Ловлю точно такие же глюки просто.

 

[Phoenix78]

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

 

[Spelin]

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

Мотание точно не причем. Если делал по точкам. У меня что с ними что без одинаково. Проверял.

 

[Phoenix78]

Мотание точно не причем. Если делал по точкам. У меня что с ними что без одинаково. Проверял.

скорее скрол глючный. замечал за ним бесконечное выполнение.

 

[sociohacker]

if ( instance.ActiveTab.IsVoid || instance.ActiveTab.IsNull )
{
    project.Variables["instance_fail"].Value = "1";
    throw new Exception("Обнаружена пустая вкладка");
}
// замер времени
DateTime now = DateTime.Now;
string test = instance.ActiveTab.Name;    // или свою команду работающую с браузером
TimeSpan Delta_Time = DateTime.Now-now;
double Time_Difference = Delta_Time.TotalMilliseconds;

if ( Time_Difference > 60000 )
{
    project.Variables["instance_fail"].Value = "1";
    throw new Exception("Обнаружено замедление выполнения команды в инстансе" );
}

Спасибо!

 

[Oleg1987]

@Phoenix78, а как ты потом зависшие инстансы убиваешь? Я вот завернул методы зенки в асинхронные функции, как выше писал. По тайм ауту вылетает ошибка. Поток закрывается, но инстанс так же продолжает висеть в процессах и не мерено жрать ресурсы

 

[Phoenix78]

@Phoenix78, а как ты потом зависшие инстансы убиваешь? Я вот завернул методы зенки в асинхронные функции, как выше писал. По тайм ауту вылетает ошибка. Поток закрывается, но инстанс так же продолжает висеть в процессах и не мерено жрать ресурсы

на файрфокс все ровно, процесс не висит. под хромом я не кручу постоянно шаблоны.
На хроме если выходит по этому методу, то поток висит и заного процесс не получается запустить минуты 4-6. я делал заметку по этому поводу в 3-м посте.
как вариант можно попробовать получать хендл окна, по нему вычислить id процесса и принудительно убивать. под хромом не получается узнавать топик окна. баг тут, но можно получить дочернее окно. осталось найти родителя главного и можно щелкать.

 

[Konrod_m]

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

 

[Phoenix78]

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

чужие шаблоны, потемки.... оставим их авторам.

 

[orka13]

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

Первое что в голову пришло: ловить по последней дате редактирования и строке файла потока в трассировке (c:\Users\Administrator\Documents\ZennoLab\Traces\). Но как их связать хз, сам не практиковал.

 

[Gfoblin]

в основном это циклы ожидания появления элемента

Вот это зло зачем вообще если не секрет?
У меня есть, но там ооооооооочень короткие циклы, когда были бесконечные - смена диза или ещё чего и шаблон вставал намертво...

 

[Phoenix78]

Вот это зло зачем вообще если не секрет?
У меня есть, но там ооооооооочень короткие циклы, когда были бесконечные - смена диза или ещё чего и шаблон вставал намертво...

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

 

[Gfoblin]

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

дык у тебя циклы бесконечные или какие? сколько ты ждёшь элемент примерно... не вижу смысла ждать его больше минуты или двух )))

 

[Phoenix78]

дык у тебя циклы бесконечные или какие? сколько ты ждёшь элемент примерно... не вижу смысла ждать его больше минуты или двух )))

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

 

[sociohacker]

@Phoenix78, подскажи, пожалуйста: заметил, что иногда происходит зависон всего шаблона/шаблонов в зенке. Например, бывают иногда, что пол часа может вообще не выполняться шаблон, т. е. ни один из 40 потоков не работает по факту. Инстансы открыты, но в них не совершается никаких действий, т. е. просто висит всё.
И самое интересное, что я вообще ничего не меняю, но через минут 20-40 всё обратно отвисает - и продолжает работать как ни в чём ни бывало.
Прикрепляю скрин. В логе 20 минут нет ни одной записи. Такого просто никак быть не должно, т. е. шаблон длится максимум минут 5. Запущен в 40 потоков. В любом случае в лог пишется в норме куча сообщений. А тут - зависон на 20 минут.

Просто подумал, что может у тебя тоже похожие глюки бывали, ну или может какие идеи есть?

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

Я думал, что это именно инстансы зависали. А, по ходу дела, они не настолько часто зависали и проблема в чём-то ещё.

Спасибо!