Agent Manager Зависает

  • Автор темы Автор темы XiNoID
  • Дата начала Дата начала
X

XiNoID

Проблема в общем-то достаточно известная.Происходит случайно и на разных агентах и серверах. Где-то реже, где-то чаще.

Раньше мирились с этой проблемой, подумаешь перезапустить сервер раз в 2-5 месяцев, не страшно.


Но теперь проблема стала повторяться чаще и имеется уже определенная причина. Суть дела такова:

Есть агент, который по расписанию работает с ФТП удаленным сервером. Если в момент этой работы происходят неполадки в работе сети (провайдера ддосят например), то этот агент намертво вешает Агент менеджера, и помочь ему может только рестарт + sig term.

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

Вижу два пути решения проблемы:

1) Либо есть какая-то глубоко зарытая настройка, которая позволит агент менеджеру самовыпилиться в такой ситуации.
2) Либо мониторить его зависание, а потом действовать по ситуации, либо ручками, либо автоматически. Вопрос в том, как же мониторить его зависание?
 
Про настройку не скажу. Про мониторинг - может, проще мониторить какой-нить другой агент? Пишете шедульного агента, который раз в 15 минут, скажем, пишет файл на диск.
Далее ср-вами ОС проверяем дату модификации файла - если не менялась, скажем, за посл. час (т.е, этот агент заведомо не выполнился неск. раз), то убиваем/перезапускаем и т.д.
 
Проблема в общем-то достаточно известная.Происходит случайно и на разных агентах и серверах. Где-то реже, где-то чаще.

Раньше мирились с этой проблемой, подумаешь перезапустить сервер раз в 2-5 месяцев, не страшно.


Но теперь проблема стала повторяться чаще и имеется уже определенная причина. Суть дела такова:

Есть агент, который по расписанию работает с ФТП удаленным сервером. Если в момент этой работы происходят неполадки в работе сети (провайдера ддосят например), то этот агент намертво вешает Агент менеджера, и помочь ему может только рестарт + sig term.

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

Вижу два пути решения проблемы:

1) Либо есть какая-то глубоко зарытая настройка, которая позволит агент менеджеру самовыпилиться в такой ситуации.
2) Либо мониторить его зависание, а потом действовать по ситуации, либо ручками, либо автоматически. Вопрос в том, как же мониторить его зависание?

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

в данном случае нужно дописать агент на проверку активности FTP - чтобы он и статус в каждую секунду считал и переоткрыть сессию мог

в общем в данном случае агент должен содержать в себе функции всех менеджеров закачки

а еще лучше чтобы он через командную строку отдавал команду на закачку - тогда агент будет работать с локальными файлами, что решает проблему в корне
 
Всё больше последнее время склоняюсь к мысли, что Java агенты, по возможности, надо выносить на какой-нибудь внешний APP сервер. От IBM видать тут помощи не дождёшся уже никогда. Зависшие Java агенты снять, в большинстве случаев, без перезагрузки сервера (а бывает что и ОС) невозможно. А если с памятью что-то накосячить, то оно и само легко может сервер повалить.

По существу вопроса: вынести работу с FTP во внешнее приложение, пусть оно что-то там дёргает в Lotus Notes когда всё уже будет готово (файл передан или получен).
 
Всё больше последнее время склоняюсь к мысли, что Java агенты, по возможности, надо выносить на какой-нибудь внешний APP сервер. От IBM видать тут помощи не дождёшся уже никогда. Зависшие Java агенты снять, в большинстве случаев, без перезагрузки сервера (а бывает что и ОС) невозможно. А если с памятью что-то накосячить, то оно и само легко может сервер повалить.

По существу вопроса: вынести работу с FTP во внешнее приложение, пусть оно что-то там дёргает в Lotus Notes когда всё уже будет готово (файл передан или получен).

Вот это правильно - причем помощи ждать не стоит от любого АПП сервера при криво написанной прикладе:D

Очень хорошие результаты получаются, когда используется DIIOP - Java код выносится куда-ть и дергает нативные домино классы как и агент.
 
Вот это правильно - причем помощи ждать не стоит от любого АПП сервера при криво написанной прикладе:)
Проблема не в кривизне (это отдельный вопрос), а в том, что Domino Administrator в большинстве случаев вообще не в курсе чем там занимаются Java-агенты и как они себя чувствуют. Нет адекватных средств контроля и мониторинга. К тому же любой APP сервер перезапустить, в случае чего, проще и безболезнее, чем зависший сервер Domino.
 
Дано: шедульный агент, работает с вордовскими документами, на клиенте всегда отрабатывает отлично, а на серваке все время не может после quit для объекта закрыть ворд, залипает и не может обрабатывать следующий документ. Помогает только shell kill... При этом на клиенте все идет отлично.
Проверено - если на сервачной машине вручную запускать - все хорошо. По расписанию - залипает.
Агент подписан серверной id, полномочия все есть.
Не могу понять, в чем разница работы с вордом в этих двух случаях.
В данном случае даже restart для АгентМенеджера не работает
Может, кто сталкивался? B)
 
Word на сервере - это ЗЛО!!! Обсуждалось уже не раз.
По существу вопроса - так "за глаза" ответить сложно. Может быть ваш Word спрашивает у вашего сервера действительно ли он хочет закрыть, сохранить и т.п. файл. Ну, а сервер ваш конечно же читать не умеет, потому и не отвечает. Второй вариант - не выгружается Word после первого запуска по расписанию и все последующие спотыкаются об уже запущенный Word. Всегда надо сначала делать GetObject и если не удалось его получить, то только тогда CreateObject.
 
Последнее редактирование модератором:
ответ - не использовать COM на сервере! https://codeby.net/threads/53756.html?vi...st&p=247138

Добавлено: по теме шедульных агентов и java - есть такой ощущ что java стала более "родной" для домины и появились в связи с чем - есть мыслЯ пинать просто задачи по расписанию на сервере
предположительно - может оказаться более "безопасным" поведение, хотя... надо тестить B)
 
статус проекта DOTS
включен в домину 9 (open social), правда - офиц. не сапортицо
 
В данном случае даже restart для АгентМенеджера не работает
Может, кто сталкивался? B)
Есть старый надежный способ - ставим рядом старенький комп с CD-Drive-ом, который отследив по реализации Мыш зависание, откроет CD-Drive, который выезжая, тычется в кнопку RESET сервера. :)
 
  • Нравится
Реакции: vital
использую WebAPI где читаю и фтп и http и все виды запросов - летает как часы, там же указываю таймауты на команды, что и вам рекомендую
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!