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.
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.
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).
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.
ngx_http_request_t can expand datas with the module context, but other
data
struct can’t use module conext?
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:
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.