hello!<br>I have understood it.<br>But why the proxy cache module add the "cache" variable in ngx_http_request_t? It can also be done in the module context.<br><br>thanks.<br><br><div class="gmail_quote">2009/6/23 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello!<br>
<div class="im"><br>
On Tue, Jun 23, 2009 at 08:26:27PM +0800, Chieu wrote:<br>
<br>
> the way of the module context can meet many requitments. But some others<br>
> can't be implemented by the module way.<br>
> for example,<br>
> In the struct"ngx_http_upstream_rr_peer_t", I want add a variable to count<br>
> how many times I haved request this upstream.<br>
> If there is a reserved pointer, I can use it point a struct I have defined<br>
> in my module. But now,I must modify the source code and when I want to<br>
> replace with a new version nginx, I have to re-modifiy the code.<br>
<br>
</div>As I said, there is no need to modify nginx code. Feel free to<br>
wrap balancer module, allocate additional memory in<br>
peer.init_upstream() handler and increment numbers on wrapped<br>
peer.get() handler.<br>
<br>
For simple wrapper around take a look at<br>
ngx_http_upstream_ip_hash_module. For a bit more complex wrapper<br>
see ngx_http_upstream_keepalive_module here:<br>
<br>
<a href="http://mdounin.ru/hg/ngx_http_upstream_keepalive/file/tip/ngx_http_upstream_keepalive_module.c" target="_blank">http://mdounin.ru/hg/ngx_http_upstream_keepalive/file/tip/ngx_http_upstream_keepalive_module.c</a><br>
<div class="im"><br>
> ngx_http_request_t can expand datas with the module context, but other data<br>
> struct can't use module conext?<br>
<br>
</div>Basically in nginx you either work with request (and here you have<br>
module contexts to store your data) or with configuration (and<br>
module configs to store your data). Most things could be easily<br>
done by pure modules without patching nginx itself, and there are<br>
lots of examples in nginx source code how to do it.<br>
<font color="#888888"><br>
Maxim Dounin<br>
</font><div><div></div><div class="h5"><br>
><br>
> thank you<br>
><br>
> 2009/6/23 Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
><br>
> > Hello!<br>
> ><br>
> > On Tue, Jun 23, 2009 at 06:05:19PM +0800, Chieu wrote:<br>
> ><br>
> > > hi, developers<br>
> > > Because of the modularity of nginx, I can extend the new function easily.<br>
> > > But there are some requirements which need to modify the original source<br>
> > > code.<br>
> > > For example:<br>
> > > I want to add a variable which records the count of requests sent to each<br>
> > > upstream. And I must add a variable into the struct<br>
> > > "ngx_http_upstream_rr_peer_t", when round robin get the upstream ,the<br>
> > > variable++ . This way, I shoud modify the source code of the upstream<br>
> > > module.<br>
> ><br>
> > You may easily write transparent upstream balancer module that<br>
> > does this (just counts and passes everything to the real<br>
> > balancer). Without nginx code modifications. It's not really<br>
> > efficient due to extra function calls, but it will work.<br>
> ><br>
> > > I think if the struct "ngx_http_upstream_rr_peer_t" have a reserved<br>
> > > pointer(void *), which reserved for others developing new modules.<br>
> > > Totally, I think the modularity of nginx just resolved the expansibility<br>
> > of<br>
> > > function. But if the I want to expand some import data like the struct<br>
> > > "ngx_http_request_t", I must modify the original source code. And if<br>
> > some<br>
> > > important struct adds a reserved pointer, I think the data of nginx will<br>
> > be<br>
> > > easily be extend.<br>
> ><br>
> > I don't really understand the question, but for any data you may<br>
> > use either your module context (every module has pointer to it's<br>
> > context stored in ngx_http_request_t) or variables (if you need<br>
> > something that survives internal redirects).<br>
> ><br>
> > Maxim Dounin<br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div><br>