Агент Run In Background Client Thread

  • Автор темы Автор темы Dragon108
  • Дата начала Дата начала
Medevic, да понятно, что геморрой - тока, в основном, за него нам деньги и платят. Если б все делалось в 2 нажатия на кнопку, на фига тогда АйТишники были б нужны? :(
 
Перенести на сервер нельзя - по разным причинам. Агент должен отрабатывать на клиенте.
Вкратце суть: после выполнения агента, в notes.ini клиента проставляется переменная, так вот, если агент остановить принудительно, то естественно это переменная не проставится, что очень плохо :( так вот вопрос и был в том, можно ли как то узнавать о принудительном завершении агента и если агент завершился принудительно, то проставлять эту переменную ...


а почему в нотес.ини сразу должно что-то прописываться?

пользователь создает документ-задание,
агент на сервере отработает его, сохранит что-то в профиле пользователя или в том же документе-задании,
а при открытии базы, если уж так хочется, записать информацию из профиля в нотес.ини
 
Эту задачу такими способами никак не решить. Пропадёт электричество, сгорит проц, уборщица полы помоет, наступит конец света и всё - задача не решена, зато усложнена.
По-моему, надо:
1) после обработки прописать в документ, например, время запуска агента. Так мы отловим обработанные документы. Папки не подходят, т.к. они плохо переносят сбои в работе.
2) отказаться от записи флага окончания всей обработки в notes.ini или ещё куда-нибудь. Потому что никогда не будет 100% гарантии, что были обработаны все документы.
3) всё-таки рассмотреть возможность обработки серверным агентом.
 
Сбои все плохо переносит... и папки и документы... тут еще и репликационные конфликты и т.д....лишнее обращение к диску при сохранении. Ладно если это не большое кол-во документов...
В общем геморроя предостаточно :(
 
Папки гораздо хуже. Уже нарвался с ними. Для серьёзных вещей лучше не использовать.
 
Medevic, а что не так с папками? Не поделитесь? :(
 
В папку "к обработке" помещались документы для обработки. У каждого документа было прописано какой сервер его обрабатывает. В папке документы были отсортированы по имени сервера. Серверный агент брал нужную коллекцию по ключу, обрабатывал и перемещал в папку "обработанные". И это нормально работало, всё реплицировалось между несколькими серверами и т.п. Пока в один момент не начались сбои на серверах. Уже не помню по какой причине. Вроде бы, часто отключали электричество. Папки после этого переставали нормально реплицироваться. Т.е. на одном сервере агент обработал документы и удалил их из папки, а на другом эти документы по-прежнему находились в папке. Всё остальное нормально реплицировалось. Потом в один момент что-то просралось и содержимое папок внезапно отреплицировалось, но как-то криво. В результате часть документов было обработано повторно, что было не очень хорошо, а точнее очень плохо. Защиты от повторной обработки в тот момент не было. Сильно повезло, что это быстро заметили. В результате всё было поправлено, папки выпилены, необходимая защита добавлена. Теперь вместо папок обычные представления. Агент после обработки меняет статус вместо перемещения по папкам. И это прекрасно работает, даже когда сервера падают. :(

Да и в целом папки ненадежны. Накроется дизайн базы, как потом узнать в какой папке был документ?
 
Нда, про репликацию я не подумал. Спасибо за инфо!
PS. Вдогонку - помнится, был у меня сделан бэкап, при котором бэкапились реплики почтовых баз. Так один хитрый юзер понаделал приватных папок. Ессно, они не реплицировались. И однажды покрылась у него база :-( Перешел в результате на прямое копирование баз с сервера...
 
Все зависит от задачи и способа использования и уж никак не от компонента.
Ага, в идеале. :( А на деле про глюки лотусни тут могут романы написать.
Вот, из последнего. В 8.5 появился замечательный метод notesDocumentCollection.StampAllMulti( document ). Суём ему документ с нужными полями, и метод делает эти поля всей коллекции. Причем, хелп говорит, что даже тип поля меняет. :) На деле же пытаемся массово проставить Readers поле, а получаем обычное текстовое поле. Прошло почти 4 года с релиза, а баг на месте.
Или вот ещё "замечательный" компонент RichText. Никогда не терял данные в нём?
 
Кстати, проверил вариант с запуском VBS-скрипта - с первого взгляда, работает...
 
создать контролирующий док (в этой или к-л базе) при запуске, по окончании - цеплять к нему лог, кот. вести из агента в файл, имя файла - по ЮНИДУ
т.о. если есть контрольный док без файла - сморим файл с его юнидом на диске юзера
запись в файл - чанками, со сбросом кэша на диск (это шобы меньше мусора было, при обрыве)
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab