suggestion about expansibility of the data

[Chieu]

hello!
I have understood it.
But why the proxy cache module add the "cache" variable in
ngx_http_request_t? It can also be done in the module context.

thanks.

2009/6/23 Maxim Dounin <mdounin at mdounin.ru>

> 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 at 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
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090624/9ffec505/attachment.html>