Максим, большое спасибо за комментарии! > Так что если вы там, e.g., хотите создавать постоянные соединения с бекендом > - то > делать это надо уже после старта рабочих процессов в них самих, а не при > чтении конфига.
А не подскажете, где лучше всего это делать. Насколько я понял по исходникам, все callback-и модуля выполняются именно master-процессом. > 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
