Так, вроде бы разобрался. init_process действительно то, что нужно.
Спасибо! > Максим, большое спасибо за комментарии! >> Так что если вы там, e.g., хотите создавать постоянные соединения с бекендом >> - то >> делать это надо уже после старта рабочих процессов в них самих, а не при >> чтении конфига. > А не подскажете, где лучше всего это делать. > По исходникам и экспериментам, похоже, что callback init_process > срабатывает как раз внутри воркера. >> Hello! >> On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote: >>> Привет, Nginx Гуру >>> >>> Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно. >>> >>> Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С >>> API. >>> Под этим API лежит в том чесле и установка TCP/IP соединения. >>> >>> Насколько я понял, правильным способом подключения к сторонней системе была >>> бы разработка unstream http модуля. >>> Проблема в том, что протокол довольно сложный и в условиях ограниченного >>> времени разбираться с ним некогда, >>> поэтому хотелось бы попользовать API, которое предоставляет система. >>> >>> Посоветуйте, плиз, по следующим вопросам >>> >>> 1. Где лучше всего хранить объекты, которые должны быть созданы и >>> инициализированы только один раз для куска конфигурации >>> server или http? >>> 2. Где лучше всего создавать объекты, которые должны присутствовать >>> единожды для конфигурации server или http (например, >>> устанавливать соединение со сторонней системой)? >>> 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное >>> api. Верно? >>> 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из >>> request handler-ов? >> In no particular order: >> 1. Конфигурацию модуля, а также глобальные сущности с ней связанные - >> правильнее всего хранить в, как это ни странно, конфиге модуля. >> Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, >> а потом при fork()'е наследуется в worker'ов. Так что если вы >> там, e.g., хотите создавать постоянные соединения с бекендом - то >> делать это надо уже после старта рабочих процессов в них самих, а >> не при чтении конфига. >> 2. Таки да, nginx - event-based сервер, и для работы со всем чем >> можно - используются event-based API. >> 3. Upstream - это точно такой же модуль, как и все остальные. >> Если вы хотите написать свой модуль, аналогичный upstream'у, я бы >> рекомендовал для начала посмотреть на upstream. >> 4. Работать с сокетами из request handler'ов - не плохо. Работать >> с ними в блокирующемся режиме - плохая идея. _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
