Hello!
On Wed, Jun 19, 2013 at 08:15:21PM +0300, Sergey Avseyev wrote:
> Привет всем,
>
> Я написал nginx модуль, для доступа к базе данных Couchbase[1]. Этот
> модуль получился немного не обычным:
>
> 1) используется библиотека libcouchbase, которая сама рулит установкой
> обработчиков на события, и выполнением собственно IO из них. Так что
> пришлось написать плагин[3], который подставляет функции nginx в виде,
> удобном для libcouchbase.
>
> 2) частично потому что IO выполняется внутри libcouchbase, как и
> маршрутизация запроса в кластер (основанная на хешировании ключа),
> пришлось отказаться от использования ngx_http_upstream_t (хотя тут я
> могу ошибаться). Кроме того libcouchbase может асинхронно получить по
> конфигурационному сокету информацию об изменении топологии кластера, и
> закрыть часть рабочих сокетов, и подготовить к открытию по требованию
> новые.
>
> В ходе тестирование оказалось, что моя реализация неплохо работает как
> с под-запросами из других модулей, так и обычными прямыми запросами.
> Но всё же нашёлся случай, когда модуль (к его исходникам у меня нет
> доступа) делает позапрос в мой, и рассчитывает, что в можно будет
> получить содержимое результата через r->upstream->buffer или статус
> через r->upstream->state->status.
Видимо, речь идёт про функциональность subrequest_in_memory,
которая в коробке используется для ssi-команды include с
параметром set
(http://nginx.org/en/docs/http/ngx_http_ssi_module.html#commands).
Оно имеет ограниченную область применимости (читай: работает
только с proxy и memcached).
> Собственно вопрос, может ли существовать модуль в экосистеме nginx,
> который не заполняет r->upstream в обработчике?
Да. Более того - большинство модулей даже и не пытаются этого
делать, простой пример - модуль static.
Если хочется, чтобы упомянутый выше случай правильно отражался в
логах - можно подсмотреть соответствующую проверку e.g. в модуле
fastcgi.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
On Wed, Jun 19, 2013 at 08:15:21PM +0300, Sergey Avseyev wrote:
> Привет всем,
>
> Я написал nginx модуль, для доступа к базе данных Couchbase[1]. Этот
> модуль получился немного не обычным:
>
> 1) используется библиотека libcouchbase, которая сама рулит установкой
> обработчиков на события, и выполнением собственно IO из них. Так что
> пришлось написать плагин[3], который подставляет функции nginx в виде,
> удобном для libcouchbase.
>
> 2) частично потому что IO выполняется внутри libcouchbase, как и
> маршрутизация запроса в кластер (основанная на хешировании ключа),
> пришлось отказаться от использования ngx_http_upstream_t (хотя тут я
> могу ошибаться). Кроме того libcouchbase может асинхронно получить по
> конфигурационному сокету информацию об изменении топологии кластера, и
> закрыть часть рабочих сокетов, и подготовить к открытию по требованию
> новые.
>
> В ходе тестирование оказалось, что моя реализация неплохо работает как
> с под-запросами из других модулей, так и обычными прямыми запросами.
> Но всё же нашёлся случай, когда модуль (к его исходникам у меня нет
> доступа) делает позапрос в мой, и рассчитывает, что в можно будет
> получить содержимое результата через r->upstream->buffer или статус
> через r->upstream->state->status.
Видимо, речь идёт про функциональность subrequest_in_memory,
которая в коробке используется для ssi-команды include с
параметром set
(http://nginx.org/en/docs/http/ngx_http_ssi_module.html#commands).
Оно имеет ограниченную область применимости (читай: работает
только с proxy и memcached).
> Собственно вопрос, может ли существовать модуль в экосистеме nginx,
> который не заполняет r->upstream в обработчике?
Да. Более того - большинство модулей даже и не пытаются этого
делать, простой пример - модуль static.
Если хочется, чтобы упомянутый выше случай правильно отражался в
логах - можно подсмотреть соответствующую проверку e.g. в модуле
fastcgi.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru