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

[fedotxxl]

Привет, люди
Грустно мне...
Скажите, как разрабатывать нормальные системы с использованием классов так, чтобы не падал е*учий сервер Lotus Notes?
А то мало того, что платформа и так достала своей кастрированностью, так и нормально работать не работает - при больших нагрузках просто заваливается сервак (это актуально для систем на классах LS)

Совет чистить память давать не нужно. Может кто подскажет, как ее контролируемо чистить? И сколько объектов в памяти сервер способен держать без падений?... и в памяти-то дело?
Кто шарит?

 

[Akupaka]

так, чтобы не падал е*учий сервер Lotus Notes

Нет такого сервера.

Может кто подскажет, как ее контролируемо чистить? И сколько объектов в памяти сервер способен держать без падений?... и в памяти-то дело?

Это тесты проводить надо. Я пока подобных работ не встречал.

 

[turumbay]

"не хочешь $рать - не мучай #опу" (с) - народная мудрость
очередная провокация? зайти на форум и опустить платформу, кормящую многих участников - это смело.
отмонтируйте /dev/hands от /dev/ass и будет вам щастье.

 

[fedotxxl]

Так, давайте успокоимся


1. Кто писал системны на классах LS?
2. Кто встречался с достаточно регулярными падениями сервера? Удалось ли до конца победить падения?
3. Кто принудительно чистил память? Каким образом (интересует не метод delete, а методика)?

 

[Akupaka]

Так, давайте успокоимся

Не сочти за грубость ))) Иди к Тохе! )) Тот тоже подобным вопросом недавно увлекался. Наверное он в отпуске сейчас - давно не видно.

 

[turumbay]

1. Кто писал системны на классах LS?

я.

2. Кто встречался с достаточно регулярными падениями сервера? Удалось ли до конца победить падения?

с регулярными падениями не встречался. те, с которыми встречался были вызваны кривизной рук кодеров ( в т.ч. моих )

3. Кто принудительно чистил память? Каким образом (интересует не метод delete, а методика)?

чистил. именно при помощи delete.

классы - они разные бывают: хочите процедурного агента, укладывающего сервер - их есть у меня
так что дело не в классах. точнее не столько в них. вам уже указывали(https://codeby.net/ipb.html?s=&showtopic=31649&view=findpost&p=146364), что нельзя держать много открытых хэндлов документа. т.е. не надо пытаца инкапсулировать коллекцию на 100,000 документов классом, содержащем список этих документов.
плюс надо помнить, что лотус плохо чистит "isolation islands".

Ссылка скрыта от гостей

it gets hung up when deallocating memory, particularly when there are object references that go across script libraries (a class in Library A contains a reference to an object whose class is declared in Library B ). The more you deallocate objects yourself with a Delete statement, the better your chances of not having a problem.

Вы написали систему. Большую систему. И она хреново работает на платформе, для которой предназначена.
Теперь вы хотите поиметь средство диагностики проблем, которое расскажет вам где в системе проблема. Вполне законное желание, особенно если переписывать систему уже поздно.
Если курение nsd не помогает - выход имхо один: пытаца локализовать проблему. Разбивать систему на куски, отключать агентов, запускать последовательно под нагрузкой. короче - искать причину падения. Возможно, что причина будет в сервере, но скорее всего - она будет в коде. Удачи.

А вообще, с таким настроением, с лотуса надо уходить. Платформа не для слабонервных

 

[ToxaRat]

Akupaka

Иди к Тохе! )) Тот тоже подобным вопросом недавно увлекался. Наверное он в отпуске сейчас - давно не видно.

в командировке, уже вернулся :lovecodeby:

fedotxxl
определись кто виноват, сервер, классы, память и т.д. а то как то настораживает что виновато всё а не ты

 

[Klido]

2. Кто встречался с достаточно регулярными падениями сервера? Удалось ли до конца победить падения?

падения всегда побеждаются :lovecodeby: иначе мы бы теряли работу очень часто

 

[fedotxxl]

ToxaRat
Похоже, что память, т.к. добавление чистки памяти позволило значительно увеличить нагрузку без падений

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

А вообще, с таким настроением, с лотуса надо уходить. Платформа не для слабонервных

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

Ссылка скрыта от гостей

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

 

[VladSh]

я. с регулярными падениями не встречался. те, с которыми встречался были вызваны кривизной рук кодеров ( в т.ч. моих )
чистил. именно при помощи delete.

Полностью поддерживаю.


Ключик к успеху в том, чтобы:

1. Не использовать в агентах на сервере объектов UI-классов.

2.

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

3. Чистить в той же процедуре, что объявил.

 

[fedotxxl]

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

Этого добиться и больше сервер падать не будет?)

Чистить в той же процедуре, что объявил.

Это не всегда возможно

Еще такой вопрос - принудительно удалять нужно только самописные объекты или же еще и LN?

 

[turumbay]

Этого добиться и больше сервер падать не будет?)

это врятли. падает все, иначе зачем существуют бэкапы?
как минимум есть еще системные ресурсы, которые нужно освобождать: файлы, соединения и т.п.
внешние библиотеки ( dll , so , всякие COM ) - также могут течь/забывать освобождать ресурсы/тупо падать

Можно также пошарить сайт вендора:
GetProfileDocument method appears to leak memory:

Ссылка скрыта от гостей

Memory leak on 0x11b7 when properties of LotusScript NotesRichTextDocLink class are set:

Ссылка скрыта от гостей

ну и вообще:

Ссылка скрыта от гостей

P.S. delete для лотусовых объектов никогда не применял( кроме случаев, когда нужно переполучить документ, но это из другой оперы )

 

[VladSh]

Чистить в той же процедуре, что объявил.

Это не всегда возможно

Это конечно идеальный вариант, для классов, предназначенных для работы какого-то функционала (которые не содержат данные) это реально.
Более в общем случае объект надо грохать на одном и том же уровне, например на уровне библиотеки или другого класса (что лучше), причём вызов "грохающего" )) метода должен быть обязательным, не зависимо от ошибки или поведения скрипта. Т.е. в идеале у класса / у любого процедурного функционала (библиотеки), инициализирующего объект самописного класса должно быть 2 функции/метода: открывающий процессы (типа Initialize) и закрывающий; элегантнее конечно это делается на классах. А уж сам верхний класс так и получится: инициализировал, поработал и грохнул, типа того:

Саб Иницыэлайз
Сет МайОбъект как Новый МайКласс
Если МайОбъект.Оупэн() Тогда
Вызов МайОбъект.Ран(параметры)
Вызов МайОбъект.Клоус()
Всё
Замочить МайОбъект
Энд Саб

 

[Akupaka]

Более в общем случае объект надо грохать на одном и том же уровне, например на уровне библиотеки или другого класса

В общем, не согласен. Простой пример: объект Б, состояние которого зависит от другого объекта А.
Программист создает объект А, создает Б, передает Б ссылку на А, поработал с Б, удаляет Б, при этом Б удаляет А. Далее ошибка работы с А.
Программист, в общем случае, не ожидает, что Б удалит А.
Частный же случай - объет А является полностью внутренним для Б, не имеет внешних связей, им же и создан - тогда удаление объектом Б объекта А оправданно вполне.

 

[ToxaRat]

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

 

[VladSh]

В общем, не согласен. Простой пример: объект Б, состояние которого зависит от другого объекта А.
Программист создает объект А, создает Б, передает Б ссылку на А...

Это не просто плохой, а очень плохой стиль кодирования... В нашем случае, это и есть источник падений сервера

Что касается LS и данной темы выделил жирным:
<!--QuoteBegin-"Бьерн Страуструп+ «Язык программирования С++»"-->
<span class="vbquote">("Бьерн Страуструп @ «Язык программирования С++»")</span><!--QuoteEBegin-->СВОД ПРАВИЛ

1. Когда вы пишите программу, то создаете конкретные представления тех понятий, которые использовались в решении поставленной задачи. Структура программы должна отражать эти понятия настолько явно, насколько это возможно.

a. Если вы считаете "нечто" отдельным понятием, то сделайте его классом.
b. Если вы считаете "нечто" существующим независимо, то сделайте его объектом некоторого класса.
c. Если два класса имеют нечто существенное, и оно является для них общим, то выразите эту общность с помощью базового класса.
d. Если класс является контейнером некоторых объектов, сделайте его шаблонным классом.

2. Если определяется класс, который не реализует математических объектов вроде матриц или комплексных чисел и не является типом низкого уровня наподобие связанного списка, то:

а. Не используйте глобальных данных.
b. Не используйте глобальных функций (не членов).
c. Не используйте общих данных-членов.
d. Не используйте функции friend (но только для того, чтобы
избежать а, b или c).
e. Не обращайтесь к данным-членам другого объекта непосредственно.
f. Не заводите в классе "поле типа"; используйте виртуальные функции.
g. Используйте функции-подстановки только как средство значительной оптимизации.[/quote]Единственное, без чего трудно обойтись - это 2-b, но если в них не используются объявленные не в самой функции самописные классы (а этого не должно быть!), это никак не влияет на падения сервера.

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

Частный и единственно правильный случай.

Добавлено:

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

Не знаю, кто писал, но я к этому сам пришёл и всегда чищу. Также чищу нотесовские объекты, содержащие другие объекты, например NotesDocumentCollection и т.п.

я еще до этой темы плотно не добрался, так как пытаюсь найти способ узнать "выгрузился ли агент по окончанию полностью"

Это вряд ли получится, разве только не написать специальную задачу нас сервере

 

[ToxaRat]

VladSh

Это вряд ли получится, разве только не написать специальную задачу нас сервере

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

 

[Akupaka]

Это не просто плохой, а очень плохой стиль кодирования

Да ну? Это не стиль, а способ реализации требуемой задачи. Ничего плохого в этом нет.
А убивать объекты не удостоверившись, что они не используются - это значит хороший стиль? )))

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

Как ты привязал это к моему примеру? Тут вовсе другой замысел описан.

Частный и единственно правильный случай.

Ты носки по какой-то конкретной системе одеваешь или как вздумается каждый отдельный раз?

e. Не обращайтесь к данным-членам другого объекта непосредственно.

И как ты это понимаешь? Если выделил.
Я понимаю как "обращение к данным объекта необходимо производить через методы доступа". Это ограничивает сказанное мною? О.о

я сейчас пытаюсь понять в каком порядке происходит Initialize/Terminate у агента

Тоха, обратись к хелпу, в нем сила ))

 

[VladSh]

Да ну? Это не стиль, а способ реализации требуемой задачи. Ничего плохого в этом нет.

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

Как ты привязал это к моему примеру? Тут вовсе другой замысел описан.

Частный случай ухода как раз от такого способа.

И как ты это понимаешь? Если выделил.
Я понимаю как "обращение к данным объекта необходимо производить через методы доступа". Это ограничивает сказанное мною?

Там ключевое слово "другого".
Хотя да, - понять можно по разному.
Общая идея всех трёх пунктов (а их я воспринимаю именно вместе) - не использовать что-то внешнее, тем более, если оно может менять одни и те же данные.
Согласен, более корректно было бы добавить " и пользоваться объектами, если они составная часть класса, только в этом классе; в исключительных случаях передавать параметром для произведения простейших действий".

Программист создает объект А, создает Б, передает Б ссылку на А, поработал с Б, удаляет Б, при этом Б удаляет А. Далее ошибка работы с А.
Программист, в общем случае, не ожидает, что Б удалит А.

Какой из этого может быть вывод? Только что хреновый программист, раз он этого не ожидает при таких условиях! )))

Альтернативы?
Либо писать "абы сейчас было быстро и удобно" и потом *цензура*ься с выпадениями сервера, либо объединить п.1-c Страуструпа (+ учитывать остальные пункты) и это, и писать нормальный код.

 

[Akupaka]

Частный случай ухода как раз от такого способа.

Не в тему. Либо ты плохо объяснил, а я плохо понял. А может проблема в ниже описанном )))

Общая идея всех трёх пунктов (а их я воспринимаю именно вместе) - не использовать что-то внешнее, тем более, если оно может менять одни и те же данные.

Ну с таким уклоном надо все описывать в одном объекте!

Только что хреновый программист, раз он этого не ожидает при таких условиях!

Ну хорошо, я хреновый программист. Если ты удаляешь объект NotesSession ты ожидаешь, что все полученные с его помощью объекты БД пропадут?
Если ты уничтожаешь объект NDocCol, ты ожидаешь, что пропадут все объекты NDoc?
Я хреновый программист.
Страуструп больше философ, не факт, что его мысли - лучшее решение для любого случая.