Разработка агентов, устойчивых для сервера

  • Автор темы Автор темы fedotxxl
  • Дата начала Дата начала
Ну хорошо, я хреновый программист.
А я, значит, охрененный... ))) Вот ты даёшь *посыпаю голову пеплом* да я не имел ввиду тебя! :) У меня ещё такое осталось, да и сейчас иногда хочется так сделать... - это всё дурацкая платформа отпечаток накладывает: "то нельзя", а "так неможна" )) - с одной стороны хочется чтобы было и настраиваемо (классы), а с другой стороны проще (процедурный подход), вот оно что-то такое и получается... (( Но люди так уже давно не пишут! И я понимаю, что они реально в другом мире, т.к. у них работает всё, а мы можем сделать только примитивное наследование классов!
Извини, я, видимо, и правда излишне категорично выразился...

Где-то я давно читал, что Домина не любит иерархий классов больше 3 уровней наследования, да и вообще самописные классы не любит... так вот на свой страх и риск начал использовать их больше (вот как выше писал), но правда стараюсь не делать большого количества наследований... так вот ничего в худшую сторону не изменилось, разве что труднее стало в них ориентироваться (процедурный подход всё-таки проще).

Если ты удаляешь объект NotesSession ты ожидаешь, что все полученные с его помощью объекты БД пропадут?
Если ты уничтожаешь объект NDocCol, ты ожидаешь, что пропадут все объекты NDoc?
Честно? Да, я именно так и ожидал, что если удалю NotesSession, то всё, из него полученное, удалится! И очень когда-то удивился, что это не так...
 
я именно так и ожидал
С таким успехом надо было ожидать красной карточки! )))
Извини, я, видимо, и правда излишне категорично выразился
Да перестань! )) Я совсем не принял это аж так категорично. Я просто имел в виду, что я таким пользуюсь и не боюсь в этом признаться. Но все зависит от ситуации.
Я тоже стараюсь лишнего не городить.
 
Akupaka
Сейчас разбираю темы по модерству, и случайно зашёл на эту. Там вверху я, видимо, неправильно понял описываемую тобой ситуацию, и в ответ нагородил такой хрени, что сейчас аж самому страшно))
Частный же случай - объет А является полностью внутренним для Б, не имеет внешних связей, им же и создан - тогда удаление объектом Б объекта А оправданно вполне.
Согласен.
Простой пример: объект Б, состояние которого зависит от другого объекта А.
Программист создает объект А, создает Б, передает Б ссылку на А, поработал с Б, удаляет Б, при этом Б удаляет А. Далее ошибка работы с А.
Программист, в общем случае, не ожидает, что Б удалит А.
Вбрасывание объекта А в конструктор/метод класса Б для выполнение внутри него метода класса А я тоже использую, но тут должно быть чёткое правило - внутри класса Б класс А, переданный вбрасыванием, не должен удаляться.

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

что тут имеется в виду ?
речь видимо о LS агентах..
такие агенты могут как-то не полностью выгружаться или что ?
 
Kee_Keekkenen
Тут целая тема-трагедия была, правда больше теоретическая)) Поищите, если интересно.
 
ToxaRat
Похоже, что память, т.к. добавление чистки памяти позволило значительно увеличить нагрузку без падений

Ребят,
я уже давно ищу четкий ответ на вопрос:
если делать систему на классах, то в каких случаях падает сервер? Кто-нить это разбирал? Например, меня бы устроил ответ "Если кешировать в классе документ, то сервер падает. Во всех остальных случаях все нормально".

Ты прав =(. Просто грустно, когда падает сервер, документы (некоторые) в кластере не реплицируются и не редактируются (ошибки разработки нет - queryModeChange пустой, формулы репликации нет), а сервер периодически падает. Устал я от этих проблем....

- перечитаю еще разок

А вы попробуйте пописать на аналогах. Особенно рекомендую Documentum, DocsVision и Sharepoint.
Думаю Lotus будете вспоминать с ностальгией и нежностью.

По поводу падений сервера:
перешел с Delphi и вначале много и упорно ошибался, поскольку был разбалован ООП и автосборщиком мусора.

Практические советы:
- Не использовать ресурсы рекурсии.
- гонять память локально при действии пользователя.
- чистить за собой.
- Для классов также полезна частичная инициализация.

Ну и один умный человек мне когда-то сказал, что программист портит любую платформу, как бы он не старался. Поскольку все мы используем не оптимальные, а быстродоступные методы.
 
Практические советы:
- Не использовать ресурсы.
- гонять память локально при действии пользователя.
- чистить за собой.
- Для классов также полезна частичная инициализация.
1,3 понятны, 2,4 хотелось бы расшифровки (по 4 - я "неразбалован":) )
 
1,3 понятны, 2,4 хотелось бы расшифровки (по 4 - я "неразбалован":) )

я там немного о своем думал опечатался - поправил.

2. Имелось ввиду не хранить постоянно огромные классы до запроса пользователя. Речь не только о глобальных переменных в данном случае.

4. В классы часто пихают множество свойств и методов и при каждом создании нового объекта(new) пытаются наполнить настройками, проинициализировать и т.д. Чтобы не кушать память помогает дергать настройки частично, необходимые и тд.
 
Нормальный такой стиль.
Все логично, внеязычно и внеплатформенно :)
Неужели кто-то пишет "как не стоит"?

Ну а как еще воспринимать такую тему?
В 90% случаев падения виноваты программисты.

Сам столкнулся с первой системой на lotus которая начисто убивала память и отрабатывала простые действия по 2 минуты.
Оказалось предыдущий программист считал, что db.search это что-то вроде select'ивного запроса и искал им все что можно. А потом рассказывал какое лотус УГ))

Поэтому ИМХО есть руки, а все остальное лирика.
 
Мы в соцсетях:

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