Thanks for your reply. I'm still a bit confused though. The registration
mechanism you're using is what the upstream module uses (which in turn uses
e.g. the round robin module).

But the example in the tutorial seems to suggest that I can use the upstream
module itself from my own module - see for example the way it passes in
ngx_http_upstream_init.

So are you saying I need to implement myself the stuff that the round robin
module does? Or can I in fact use the existing upstream module to make a
request?

Sorry for being slow,

Edward


-----Original Message-----
From: Piotr Sikora [mailto:piotr.sikora@frickle.com]
Sent: 07 January 2010 00:43
To: nginx-devel@nginx.org
Subject: Re: Proxying module query

> I'm struggling a bit to understand how a module can indicate which
> server to issue a request to - the example proxy module code
> presumably does this via the config for the upstream module. If I'm
> just interested in sending a query to a known host/port, what's the
> best way of doing this?

Using function registered with r->upstream->peer.get. There is number of
examples how to do this in nginx base: upstream_round_robin,
upstream_ip_hash and in 3rd party modules: upstream_hash, upstream_fair,
ngx_supervisord.

In short:
1) during configuration phase module sets pointer to init function in
uscf->peer.init_upstream,
2) during initialization phase module sets pointer to per-request init
function in uscf->peer.init and pointer to some data (which usually contains
list of backend servers) in uscf->peer.data.
3) as each request is processed, function at uscf->peer.init is called and
it, among other things, sets stuff like r->upstream->peer.get,
r->upstream->peer.free and r->upstream->peer.tries.
4) before connecting to upstream server, function at r->upstream->peer.get
is called and it sets information about which backend server nginx should
connect to in (ngx_peer_connection_t *) pc,
5) after request is processed from the upstream, function at
r->upstream->peer.free is called to "free resources".

That should be about it.

Best regards,
Piotr Sikora < piotr.sikora@frickle.com >


_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel


_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel