NGINX Module - create variables
Hi, I would like to create a small module which execute some routines, returns an NGX_OK, somewhat similar in concept to http://blog.zhuzhaoyuan.com/2009/08/creating-a-hello-world-nginx-module/ However I would like once the module executes to create variables such as $my_var which would be accessible via config files to other blocks or to the same location block. I am aware of the register_variable option, with ngx_http_variable_t *var, *v; - but the examples I have seen so far, execute the module only once this variable is loaded in the config file. What I would like is being able to define a couple of config variables once my module is loaded. Is this possible at all? If so, could you point me to a sample/module which does this so I can learn from it? Many thanks, Alex ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] Fixed null pointer dereference with $upstream_cache_last...
details: http://hg.nginx.org/nginx/rev/b7b8e2fa7ebd
branches:
changeset: 5453:b7b8e2fa7ebd
user: Ruslan Ermilov r...@nginx.com
date: Tue Dec 03 15:11:24 2013 +0400
description:
Fixed null pointer dereference with $upstream_cache_last_modified.
diffstat:
src/http/ngx_http_upstream.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diffs (13 lines):
diff -r b7bf4671bb7b -r b7b8e2fa7ebd src/http/ngx_http_upstream.c
--- a/src/http/ngx_http_upstream.c Fri Nov 29 17:23:47 2013 +0400
+++ b/src/http/ngx_http_upstream.c Tue Dec 03 15:11:24 2013 +0400
@@ -4555,7 +4555,8 @@ ngx_http_upstream_cache_last_modified(ng
{
u_char *p;
-if (!r-upstream-conf-cache_revalidate
+if (r-upstream == NULL
+|| !r-upstream-conf-cache_revalidate
|| r-upstream-cache_status != NGX_HTTP_CACHE_EXPIRED
|| r-cache-last_modified == -1)
{
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: NGX_INT32_LEN and NGX_INT64_LEN
Hello! On Mon, Dec 02, 2013 at 03:44:53PM -0800, Dean Pucsek wrote: Hello, While reading through the source code for nginx I came across the following two lines in ngx_config.h #define NGX_INT32_LEN (sizeof(-2147483648) - 1) #define NGX_INT64_LEN (sizeof(-9223372036854775808) - 1) I was wondering if someone could explain the intention of these lines to me because it is not clear. My understanding is that using sizeof() on a string will return the number of characters in that string. Conversely, I get the feeling these lines are supposed to somehow act as replacements for INT32_MAX and INT64_MAX in stdint.h. These macros are used as a maximum length of a string representation of the relevant types. Note _LEN, not _MAX. Relevant maximum value for int32_t is NGX_MAX_INT32_VALUE defined below in the same file. Looking at code where these #define’s are used doesn’t really help clarify things either. For example, in nginx.c there is: var = ngx_alloc(sizeof(NGINX_VAR) + cycle-listening.nelts * (NGX_INT32_LEN + 1) + 2, cycle-log); The code clearly allocates memory, but it’s not clear why the allocation is a multiple of NGX_INT32_LEN (or why we’re adding 1, or 2 for that matter). Any direction would be much appreciated. This code allocates memory for the NGINX=x;y;z;\0 string, where x, y, z - are string representations of listening sockets. The + 1 is for ; after each socket. The + 2 is for = and trailing \0 (well, it looks like a only + 1 is actually needed here, as sizeof(NGINX_VAR) already includes an extra byte). -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] Improved code readablity in ngx_http_upstream_init_round...
details: http://hg.nginx.org/nginx/rev/359f49a84f87 branches: changeset: 5454:359f49a84f87 user: Vladimir Homutov v...@nginx.com date: Tue Dec 03 17:12:16 2013 +0400 description: Improved code readablity in ngx_http_upstream_init_round_robin(). Changed initialization order of the peer structure in one of the cases to be in line with the rest. No functional changes. diffstat: src/http/ngx_http_upstream_round_robin.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diffs (19 lines): diff -r b7b8e2fa7ebd -r 359f49a84f87 src/http/ngx_http_upstream_round_robin.c --- a/src/http/ngx_http_upstream_round_robin.c Tue Dec 03 15:11:24 2013 +0400 +++ b/src/http/ngx_http_upstream_round_robin.c Tue Dec 03 17:12:16 2013 +0400 @@ -79,12 +79,12 @@ ngx_http_upstream_init_round_robin(ngx_c peers-peer[n].sockaddr = server[i].addrs[j].sockaddr; peers-peer[n].socklen = server[i].addrs[j].socklen; peers-peer[n].name = server[i].addrs[j].name; +peers-peer[n].weight = server[i].weight; +peers-peer[n].effective_weight = server[i].weight; +peers-peer[n].current_weight = 0; peers-peer[n].max_fails = server[i].max_fails; peers-peer[n].fail_timeout = server[i].fail_timeout; peers-peer[n].down = server[i].down; -peers-peer[n].weight = server[i].weight; -peers-peer[n].effective_weight = server[i].weight; -peers-peer[n].current_weight = 0; n++; } } ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Nginx Logging to Zeromq Module - Sparkngin
2013/11/16 Steve Morin st...@stevemorin.com: Does anyone have experience integrating zeromq with Nginx. I am looking for some pointers, to see what concerns I should look out for. I am trying to contribute this code to a open source project. -Steve This seems to me being a good template for what you want to accomplish: [1] http://www.binpress.com/app/nginx-redislog-module/998 Keep in mind that »ØMQ sockets are not threadsafe« and don't share them between threads. [2] http://zguide.zeromq.org/page:all#Multithreading-with-MQ See also: [3] http://forum.nginx.org/read.php?2,243942,243986#msg-243986 (master process → init_module callback; don't define sockets here; zmq_init goes here) [4] http://www.evanmiller.org/nginx-modules-guide.html#definition A note on performance: • Use zero-copy wherever possible. (I would make a custom string an optional last part of a message.) — [5] http://zeromq.org/blog:zero-copy • Does ØMQ have UDP or similar for PUB sockets? If so, use that. • I guess that logging or queuing through Redis will perform better than utilizing ØMQ for that matter iff everything is done on one machine under high load. -- Mark ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] Added support for TCP_FASTOPEN supported in Linux = 3.7.1.
details: http://hg.nginx.org/nginx/rev/692afcea9d0d
branches:
changeset: 5456:692afcea9d0d
user: Mathew Rodley mat...@rodley.com.au
date: Tue Dec 03 22:07:03 2013 +0400
description:
Added support for TCP_FASTOPEN supported in Linux = 3.7.1.
---
auto/unix | 12
src/core/ngx_connection.c | 32
src/core/ngx_connection.h | 4
src/http/ngx_http.c | 4
src/http/ngx_http_core_module.c | 21 +
src/http/ngx_http_core_module.h | 3 +++
6 files changed, 76 insertions(+)
diffstat:
auto/unix | 12
src/core/ngx_connection.c | 32
src/core/ngx_connection.h | 4
src/http/ngx_http.c | 4
src/http/ngx_http_core_module.c | 23 +++
src/http/ngx_http_core_module.h | 3 +++
6 files changed, 78 insertions(+), 0 deletions(-)
diffs (166 lines):
diff --git a/auto/unix b/auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -344,6 +344,18 @@ ngx_feature_test=setsockopt(0, IPPROTO_
. auto/feature
+ngx_feature=TCP_FASTOPEN
+ngx_feature_name=NGX_HAVE_TCP_FASTOPEN
+ngx_feature_run=no
+ngx_feature_incs=#include sys/socket.h
+ #include netinet/in.h
+ #include netinet/tcp.h
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test=setsockopt(0, IPPROTO_TCP, TCP_FASTOPEN, NULL, 0)
+. auto/feature
+
+
ngx_feature=TCP_INFO
ngx_feature_name=NGX_HAVE_TCP_INFO
ngx_feature_run=no
diff --git a/src/core/ngx_connection.c b/src/core/ngx_connection.c
--- a/src/core/ngx_connection.c
+++ b/src/core/ngx_connection.c
@@ -82,6 +82,10 @@ ngx_create_listening(ngx_conf_t *cf, voi
ls-setfib = -1;
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+ls-fastopen = -1;
+#endif
+
return ls;
}
@@ -209,6 +213,21 @@ ngx_set_inherited_sockets(ngx_cycle_t *c
#endif
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+
+if (getsockopt(ls[i].fastopen, IPPROTO_TCP, TCP_FASTOPEN,
+ (void *) ls[i].fastopen, olen)
+== -1)
+{
+ngx_log_error(NGX_LOG_ALERT, cycle-log, ngx_socket_errno,
+ getsockopt(TCP_FASTOPEN) %V failed, ignored,
+ ls[i].addr_text);
+
+ls[i].fastopen = -1;
+}
+
+#endif
+
#if (NGX_HAVE_DEFERRED_ACCEPT defined SO_ACCEPTFILTER)
ngx_memzero(af, sizeof(struct accept_filter_arg));
@@ -582,6 +601,19 @@ ngx_configure_listening_sockets(ngx_cycl
}
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+if (ls[i].fastopen != -1) {
+if (setsockopt(ls[i].fd, IPPROTO_TCP, TCP_FASTOPEN,
+ (const void *) ls[i].fastopen, sizeof(int))
+== -1)
+{
+ngx_log_error(NGX_LOG_ALERT, cycle-log, ngx_socket_errno,
+ setsockopt(TCP_FASTOPEN, %d) %V failed,
ignored,
+ ls[i].fastopen, ls[i].addr_text);
+}
+}
+#endif
+
#if 0
if (1) {
int tcp_nodelay = 1;
diff --git a/src/core/ngx_connection.h b/src/core/ngx_connection.h
--- a/src/core/ngx_connection.h
+++ b/src/core/ngx_connection.h
@@ -80,6 +80,10 @@ struct ngx_listening_s {
int setfib;
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+int fastopen;
+#endif
+
};
diff --git a/src/http/ngx_http.c b/src/http/ngx_http.c
--- a/src/http/ngx_http.c
+++ b/src/http/ngx_http.c
@@ -1811,6 +1811,10 @@ ngx_http_add_listening(ngx_conf_t *cf, n
ls-setfib = addr-opt.setfib;
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+ls-fastopen = addr-opt.fastopen;
+#endif
+
return ls;
}
diff --git a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c
--- a/src/http/ngx_http_core_module.c
+++ b/src/http/ngx_http_core_module.c
@@ -3041,6 +3041,9 @@ ngx_http_core_server(ngx_conf_t *cf, ngx
#if (NGX_HAVE_SETFIB)
lsopt.setfib = -1;
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+lsopt.fastopen = -1;
+#endif
lsopt.wildcard = 1;
(void) ngx_sock_ntop(lsopt.u.sockaddr, lsopt.socklen, lsopt.addr,
@@ -3989,6 +3992,9 @@ ngx_http_core_listen(ngx_conf_t *cf, ngx
#if (NGX_HAVE_SETFIB)
lsopt.setfib = -1;
#endif
+#if (NGX_HAVE_TCP_FASTOPEN)
+lsopt.fastopen = -1;
+#endif
lsopt.wildcard = u.wildcard;
#if (NGX_HAVE_INET6 defined IPV6_V6ONLY)
lsopt.ipv6only = 1;
@@ -4027,6 +4033,23 @@ ngx_http_core_listen(ngx_conf_t *cf, ngx
continue;
}
#endif
+
+#if (NGX_HAVE_TCP_FASTOPEN)
+if (ngx_strncmp(value[n].data, fastopen=, 9) == 0) {
+lsopt.fastopen = ngx_atoi(value[n].data + 9, value[n].len - 9);
+lsopt.set = 1;
+lsopt.bind = 1;
+
+if (lsopt.fastopen == NGX_ERROR) {
+ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
+ invalid fastopen \%V\,
Re: NGX_INT32_LEN and NGX_INT64_LEN
On December 3, 2013 at 4:38:18 AM, Maxim Dounin (mdou...@mdounin.ru) wrote: Hello! On Mon, Dec 02, 2013 at 03:44:53PM -0800, Dean Pucsek wrote: Hello, While reading through the source code for nginx I came across the following two lines in ngx_config.h #define NGX_INT32_LEN (sizeof(-2147483648) - 1) #define NGX_INT64_LEN (sizeof(-9223372036854775808) - 1) I was wondering if someone could explain the intention of these lines to me because it is not clear. My understanding is that using sizeof() on a string will return the number of characters in that string. Conversely, I get the feeling these lines are supposed to somehow act as replacements for INT32_MAX and INT64_MAX in stdint.h. These macros are used as a maximum length of a string representation of the relevant types. Note _LEN, not _MAX. Relevant maximum value for int32_t is NGX_MAX_INT32_VALUE defined below in the same file. Noted, sounds like this may be a case of not fully reading ngx_config.h on my part. Looking at code where these #define’s are used doesn’t really help clarify things either. For example, in nginx.c there is: var = ngx_alloc(sizeof(NGINX_VAR) + cycle-listening.nelts * (NGX_INT32_LEN + 1) + 2, cycle-log); The code clearly allocates memory, but it’s not clear why the allocation is a multiple of NGX_INT32_LEN (or why we’re adding 1, or 2 for that matter). Any direction would be much appreciated. This code allocates memory for the NGINX=x;y;z;\0 string, where x, y, z - are string representations of listening sockets. The + 1 is for ; after each socket. The + 2 is for = and trailing \0 (well, it looks like a only + 1 is actually needed here, as sizeof(NGINX_VAR) already includes an extra byte). I had a suspicion that it was something like that but I didn’t quite get the pieces together. Thanks for the clarification. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
