Re: Модуль для доступа к базе данных, но без ngx_http_upstream_t

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru