Создать несколько сервисов из одного

← →
msgipss (2004-12-29 07:20) [0]

Не совсем понятно из названия, сорри. Задача в следующем:
Я сделал сервис winnt, при запуске он читает конфигурационыый файл и работает в соответствии с ним.
А я хочу запустить его еще раз с др.файлом конфигурации, чтобы работал тоже. Т.е. в принципе сервисы одни и те же (код один и тот) но работают они по разному в соответствии с конфигурацией. И управлять ими соответственно можно по отдельности.
Например при регистраци сервиса, он читает описание и регистрируется под тем именем что прочитал в описании.
Как это можно сделать - или никак ???

← →
Digitman © (2004-12-29 08:29) [1]

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

imho, регистрировать один и тот же физический сервис под разными именами как минимум не умно .. да и SCM вроде бы не пропустит фокус с многократной регистрацией одного и того же исп.файла сервиса, неважно под каким именем

← →
Digitman © (2004-12-29 08:30) [2]

> вроде бы не пропустит

вру, пропустит .. но все равно не умно это ..

← →
sniknik © (2004-12-29 08:57) [3]

> imho, регистрировать один и тот же физический сервис под разными именами как минимум не умно ..
мелкософт не умная компания... посмотри в скольких сервисах исполняемым является один services.exe (штук 6-8). ;о))

> Как это можно сделать - или никак ???
можно. но описание читать не обязательно, можно даже одно указать, важнее то, что, там когда регистрируется сервис указывается процедура "точка входа", укажеш две разных будет практически 2 сервиса в одном.
а уж предусмотреть разные регистрации в зависимости от какогото дополнительного параметра при регистации, думаю просто.

вот только не знаю можно ли так сделать с дельфевским сервисом (просто не делал и вряд ли буду, и разбиратся неохота), на winapi элементарно (другое дело что все остальное усложняется) ;о)).

вот посмотри, обрати внимание на регистрацию (то что с параметром /install)
http://delphi.chertenok.ru/forum/my_download.php?tema=del&action=show&id=173
(только не спрашивай конкретики, я уже гдето 2года как этим не занимаюсь, практически вот этот тест это последнее что написал)

← →
Digitman © (2004-12-29 09:16) [4]

> sniknik © (29.12.04 08:57) [3]

> мелкософт не умная компания

> посмотри в скольких сервисах исполняемым является один services.exe
> (штук 6-8)

умная или не умная, но число одновременно работающих services.exe-процессов - не показатель "умности"

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

в Делфи при использовании TServiceApplication множество различных и одновременно работоспособных сервисов в одном и том сервис-приложении реализуется до безобразия просто, "одним махом руки" - всего лишь добавляется новый компонент-наследник TService.. при регистрации все сервисы в составе сервис-приложения будут автоматически зарегистрированы под указанными именами .. при старте одного или более сервисов из состава этого сервис-приложения сервис-процесс стартует в единственном экземпляре и завершается после стопа последнего из завершаемых его сервисов

← →
msgipss (2004-12-29 10:33) [5]

Спасибо, буду смотреть, а насчет того зчем мне это ?
Просто управлять этими сервисами проще, остановил один сервис обработки одной системе, все остальное работает, т.е. независимость и просто в обслуживании и т.д.
Можно конечно сделать наверное остановку потоков этом же самом сервисе, но это немного сложнее.. или я что то не то говорю 8))

← →
Digitman © (2004-12-29 10:38) [6]

> это немного сложнее.. или я что то не то говорю

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

← →
msgipss (2004-12-29 10:46) [7]

Извините, немного не понял насчет TServiceApplication, разницы я не нашел между ним и прилодением TService и там и там один сервис.
Насколько я понял то можно создать один класс от TService, и где то ... создать столько объектов этих сервисов (со своими именами и т.д.) сколько нужно. И все они зарегистрируются в системе, и ими можно будет управлять каждой в отдельности.
Насчет точки входа я не понял, можно по подробнее(можно ссылку 8) ), и нужна ли она в данном случае ?

← →
Digitman © (2004-12-29 11:05) [8]

> не понял насчет TServiceApplication, разницы я не нашел
> между ним и прилодением TService и там и там один сервис

TServiceApplication - это класс, предназначенный для регистрации, диспетчеризации и управления одним или более сервисов, реализованных в рамках ДАННОГО приложения

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

> где то ... создать столько объектов этих сервисов (со своими
> именами и т.д.) сколько нужно

зачем же "где-то" ?
вот ты создал сервисное приложение (New -> ServiceApplication), при этом визард сгенерировал щаблон проекта этого приложения, в котором будет использоваться один-единственный объект ТServiceApplication, и по умолчанию добавил в этот проект один юнит с шаблоном класса-наследника TService, т.е. сделал шаблон сервис-приложения, реализующего по умолчанию только один сервис

прямо в дизайн-тайм ты можешь (New -> Service) добавить в проект дополнительные сервисы, столько сколько тебе нужно

после сборки проекта в ходе его регистрации (/INSTALL) все сервисы, которые есть в проекте, будут зарегистрированы в SCM отдельными сервисами, каждым из которых можно управлять отдельно

← →
DiamondShark © (2004-12-29 11:06) [9]

> но все равно не умно это ..

А мотивировать можно?
Желательно, как-нибудь иначе, чем "мне не понятно зачем это нужно".

← →
Digitman © (2004-12-29 11:25) [10]

> DiamondShark © (29.12.04 11:06) [9]

нет ну а в чем состоит тайный смысл создания фактически кучи алиасов одного и того же сервиса ?

как говаривал одим мой знакомый, "понятно что лошадь, но только с рогами")

← →
msgipss (2004-12-29 11:29) [11]

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

← →
msgipss (2004-12-29 11:32) [12]

сорри не прочитал предыдущие сообщения, были проблемы с инетом, спасибо большое, буду пробовать... 8))

← →
DiamondShark © (2004-12-29 12:05) [13]

> Digitman © (29.12.04 11:25) [10]

Ну пример из жизни.
Есть некий SQL-сервер. В настройках ему можно указать, какой коммуникационный протокол использовать (TCP, IPX, pipes, shared memory), разные TCP-порты или конкретный сетевой адаптер, если на машине их нескольколько. Разные настойки кэша, всякие опции, касающиеся SQL, и проча, и проча.

И вот, допустим, я хочу запустить на одной машине один экземпляр сервера для TCP подсетки на одном адаптере, при этом задать ограничение на количество worker threads, но кэша дать побольше (вот такая специфика задачи), другой экземпляр запустить для IPX протокола на другом адаптере, а третий экземпляр запустить с share mem клиентом, с ограничением на один коннект -- я на нём экспериментировать буду, причём, если я вдруг умудрюсь этот сервис завалить, чтоб это не повлияло на другие экземпляры.

Задачи, по сравнению с другими, редко возникающие, но ведь возникающие.

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

← →
Digitman © (2004-12-29 12:22) [14]

> мы ту же функциональность "даром".

надо понимать, "даром имеем" ?

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

← →
DiamondShark © (2004-12-29 12:50) [15]

Иметь фичу и усложнять программу или
Иметь фичу и не усложнять программу.

Тут и спорить-то не о чем.

← →
Digitman © (2004-12-29 12:53) [16]

> Иметь фичу и не усложнять программу

+ .. но требовать при этом от системы ощутимые доп.ресурсы

← →
msgipss (2004-12-29 13:31) [17]

Кстати мастера вопрос по потокам сразу, Вы уж извините если опять нелепый.
После того как создали класс от thread, выполняется его метод Execute, и если мы указали FreeOnTerminate := false то после окончания метода Execute объект не разрушается. А если мне нужно подождать с выполнением Execute (например подготовить внутренние структуры), я в начале метода Execute пишу код.
while BBegin=False do begin Synchronize(CheckBegin);Sleep(3000);end; где проверяю, если готово (признак готовности получаю из осн.потока программы) то иду дальше
....
затем что то выполняю, попутно запуская таймер, процедура заканчивается.
таймер каждую минуту вызывает событие и делаются отпределенные действия. Когда это мне нужно я разрушаю этот объект извне..
Правильны ли мои действия, если мне нужно проводить периодически какую то обработку.

← →
DiamondShark © (2004-12-29 13:54) [18]

> + .. но требовать при этом от системы ощутимые доп.ресурсы

Собственно, доп.ресурсы -- это ресурсы на копию процесса.
В приведённом примере ресурсы, требуемые на исполнение прикладной задачи в несколько раз превышают ресурсы на создание процесса.
К чему эта ловля блох?

А усложнение может обойтись дороже.

В любом случае, как выяснилось, это вовсе даже не однозначно "не умно", а совсем даже предмет анализа и решения.
Ы?

← →
DiamondShark © (2004-12-29 14:04) [19]

> А если мне нужно подождать с выполнением Execute (например
> подготовить внутренние структуры), я в начале метода Execute
> пишу код.

Лучше в конструкторе:

constructor TMyThread.Create;
begin
inherited Create(true); // создаём в "подвешенном" состоянии
// инициализация
Resume;
end;

А если подготовкой занимается другой поток, то почему бы просто не создавать новый поток, пока всё не готово?

← →
Digitman © (2004-12-29 14:16) [20]

> Собственно, доп.ресурсы -- это ресурсы на копию процесса

это отолько твое imho ?

> ресурсы, требуемые на исполнение прикладной задачи в несколько
> раз превышают ресурсы на создание процесса

оперируешь опять же своим imho, а не фактами

Ы ?

> А усложнение может обойтись дороже

А чесать репу насчет потенциального расширения функц-ти будущего сервиса, согласись уж, нужно вовсе не тогда, когда все уже слеплено-продано-впарено и денюжки за это оплаченные съедены-пропиты до копейки, а именно тогда когда верстается и утверждается ТЗ (неважно в каком виде)

Ку ?

← →
DiamondShark © (2004-12-29 14:27) [21]

> это отолько твое imho ?

Имеешь другое ho -- излагай. А не фразочками бросайся.

> оперируешь опять же своим imho, а не фактами

Иди в пень. Я тебе пример привёл. Реального продукта.

← →
Суслик © (2004-12-29 14:36) [22]

> constructor TMyThread.Create;
> begin
> inherited Create(true); // создаём в "подвешенном" состоянии
> // инициализация
> Resume;
> end;

в рамках дельфи6 (может и более ранних) делать resume в конструкторе не есть хорошо: если поток отработает очень быстро, то долго можно ошибки искать. Деталей не помню, но возможно, что такое может быть при FreeOnTerminate = true. А может и нет (не помню). В любом случае в рамках d6 можно написать

constructor TMyThread.Create; begin inherited Create(false); // создаём в "подвешенном" состоянии // инициализация end;

разницы никакой, т.к. все равно resume в aftercontruction будет.

-----------------
По поводу многоликости сервиса, поддерживаю Акуличева. Он привел реальный пример.

← →
Digitman © (2004-12-29 14:36) [23]

> DiamondShark © (29.12.04 14:27) [21]

> Иди в пень

Сударь, ты - хам. Твердолобый причем. Смысл твердолобости еще понятен, но хамства - увы .. кажется, дискуссия не выходила пока за рамки ...

Тебе был простейший намек (вовсе не подкол !) - приведи конкретные факты (пусть даже по своей ситуации), а не домыслы, коих у всех у нас достаточно !

← →
Digitman © (2004-12-29 14:43) [24]

> msgipss (29.12.04 13:31) [17]

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

constructor TMyThread.Create(..)
begin
// .. здесь ..
inherited Create(..);
end;

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

← →
DiamondShark © (2004-12-29 14:52) [25]

> Digitman © (29.12.04 14:36) [23]

Чем тебе приведённый пример не нравится?

← →
Digitman © (2004-12-29 14:54) [26]

> DiamondShark © (29.12.04 14:52) [25]

тем что [13] и [18] не вяжутся пока никак

> Digitman © (29.12.04 14:54) [26]

А должны?

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

А 18, ты уж извиняй, но возражение о "дополнительных ресурсах" было от тебя. Причём, обосновать ты его не потрудился. Я что-то не правильно сказал? Ну так скажи как правильно! Тебе ведь известно, какие ресурсы расходуются, перечислить же не трудно.
А ты хернёй маешся... Намёки какие-то намекаешь.

Ещё один пример. Всё тот же SQL-сервер.
Он допускает установку внешних UDF. В принципе, любая UDF может свалить процесс сервиса.
Я хочу запустить две БД для разных задач, но изолировать их, чтобы критическая ошибка в одной не выбивала другую.

> возражение о "дополнительных ресурсах" было от тебя. Причём,
> обосновать ты его не потрудился

мне потрудиться привести монстрообразные структуры KPROCESS, KTHREAD и все те что с ними неразрывно связаны ? мне объяснять тебе, что все эти структуры требуют ресурсов ?

> UDF

UDF исполняется в АП того процесса, что ее грузит и задействует .. и это не имеет никакого отношения к процессу твоего сервиса, стартующего экз-р сиквэл-сервера с теми или иными параметрами

2 Digitman © (29.12.04 15:45) [29]
Насколько я понял из ещё [13]
экз-р сиквэл-сервера с теми или иными параметрами - и есть тот самый сервер-сервис в одном лице.

Началось "пускание дурочки".
Ню-ню. Развлекайся...

> Cobalt © (29.12.04 16:44) [30]

> Насколько я понял из ещё [13]

не очевидно.

если ув.DiamondShark сотворяет свой собственный сиквел-сервис, то это, imho, - из другой оперы)

2 Digitman ©
Ну, писать сервис, который предназначен только для того, что бы в зависимости от параметров, стартует другой сервис (с различными параметрами) - на это моя фантазия явно неспособна ;-)

2 DiamondShark ©
А вы используете InterBase или FireBird?

и вновь крайним окажусь я ?.. и "кишиневские" намеки лупят таки по=моему "сранолюбию" ...

> Суслик © (29.12.04 17:25) [33]
> Что значит выражение?

Не правильно сказал. "Подпустить дурочку".
Это ещё у Райкина было.

> Cobalt © (29.12.04 17:54) [35]
> 2 DiamondShark ©
> А вы используете InterBase или FireBird?

Sybase ASA.
Я про него говорил.

Создать несколько сервисов из одного Найти похожие ветки