Hello!

On Tue, Jun 23, 2009 at 08:26:27PM +0800, Chieu wrote:

> the way of the module context can meet many requitments. But some others
> can't be implemented by the module way.
> for example,
> In the struct"ngx_http_upstream_rr_peer_t", I want add a variable to count
> how many times I haved request this upstream.
> If there is a reserved pointer, I can use it point a struct I have defined
> in my module. But now,I must modify the source code and when I want to
> replace with a new version nginx, I have to re-modifiy the code.

As I said, there is no need to modify nginx code. Feel free to
wrap balancer module, allocate additional memory in
peer.init_upstream() handler and increment numbers on wrapped
peer.get() handler.

For simple wrapper around take a look at
ngx_http_upstream_ip_hash_module. For a bit more complex wrapper
see ngx_http_upstream_keepalive_module here:

http://mdounin.ru/hg/ngx_http_upstream_keepalive/file/tip/ngx_http_upstream_keepalive_module.c

> ngx_http_request_t can expand datas with the module context, but other data
> struct can't use module conext?

Basically in nginx you either work with request (and here you have
module contexts to store your data) or with configuration (and
module configs to store your data). Most things could be easily
done by pure modules without patching nginx itself, and there are
lots of examples in nginx source code how to do it.

Maxim Dounin

>
> thank you
>
> 2009/6/23 Maxim Dounin <mdounin@mdounin.ru>
>
> > Hello!
> >
> > On Tue, Jun 23, 2009 at 06:05:19PM +0800, Chieu wrote:
> >
> > > hi, developers
> > > Because of the modularity of nginx, I can extend the new function easily.
> > > But there are some requirements which need to modify the original source
> > > code.
> > > For example:
> > > I want to add a variable which records the count of requests sent to each
> > > upstream. And I must add a variable into the struct
> > > "ngx_http_upstream_rr_peer_t", when round robin get the upstream ,the
> > > variable++ . This way, I shoud modify the source code of the upstream
> > > module.
> >
> > You may easily write transparent upstream balancer module that
> > does this (just counts and passes everything to the real
> > balancer). Without nginx code modifications. It's not really
> > efficient due to extra function calls, but it will work.
> >
> > > I think if the struct "ngx_http_upstream_rr_peer_t" have a reserved
> > > pointer(void *), which reserved for others developing new modules.
> > > Totally, I think the modularity of nginx just resolved the expansibility
> > of
> > > function. But if the I want to expand some import data like the struct
> > > "ngx_http_request_t", I must modify the original source code. And if
> > some
> > > important struct adds a reserved pointer, I think the data of nginx will
> > be
> > > easily be extend.
> >
> > I don't really understand the question, but for any data you may
> > use either your module context (every module has pointer to it's
> > context stored in ngx_http_request_t) or variables (if you need
> > something that survives internal redirects).
> >
> > Maxim Dounin
> >
> >