hi,
i understand that NGX_AGAIN is returned when a chain could not be send
because more data cannot be buffered on that socket.
I need to understand the following: in my case, when i receive a request, i
start a timer every 10ms and send out some data, then i create a new timer
every10ms until i decide to finish sending out data (video frames).
But if in some triggered callback by the timer the
ngx_http_output_filter(..) returns NGX_AGAIN *i assume* NginX will send
that chain as soon as the socket becomes available again. But after that
happens, how can i restore my timer cycle ?
thnks.
J.Z.
Hello!
Akos Gyimesi reported a request hang (downstream connections stuck in
the CLOSE_WAIT state forever) regarding use of proxy_cache_lock in
subrequests.
The issue is that when proxy_cache_lock_timeout is reached,
ngx_http_file_cache_lock_wait_handler calls
r->connection->write->handler() directly, but
r->connection->write->handler is (usually) just
ngx_http_request_handler, which simply picks up r->connection->data,
which is *not* necessarily the current (sub)request, so the current
subrequest may never be continued nor finalized, leading to an
infinite request hang.
The following patch fixes this issue for me. Comments welcome!
Thanks!
-agentzh
--- nginx-1.4.3/src/http/ngx_http_file_cache.c 2013-10-08
05:07:14.000000000 -0700
+++ nginx-1.4.3-patched/src/http/ngx_http_file_cache.c 2013-10-26
14:47:56.184041728 -0700
@@ -432,6 +432,7 @@ ngx_http_file_cache_lock_wait_handler(ng
ngx_uint_t wait;
ngx_msec_t timer;
ngx_http_cache_t *c;
+ ngx_connection_t *conn;
ngx_http_request_t *r;
ngx_http_file_cache_t *cache;
@@ -471,7 +472,10 @@ wakeup:
c->waiting = 0;
r->main->blocked--;
- r->connection->write->handler(r->connection->write);
+
+ conn = r->connection;
+ r->write_event_handler(r);
+ ngx_http_run_posted_requests(conn);
}
Hi,
I'm trying to understand how the shared memory pool works inside the Nginx.
To do that, I made a very small module which create a shared memory zone
with 2097152 bytes,
and allocating and freeing blocks of memory, starting from 0 and increasing
by 1kb until the allocation fails.
The strange parts to me were:
- the maximum block I could allocate was 128000 bytes
- each time the allocation fails, I started again from 0, but the maximum
allocated block changed with the following profile
128000
87040
70656
62464
58368
54272
50176
46080
41984
37888
33792
29696
This is the expected behavior?
Can anyone help me explaining how shared memory works?
I have another module which do an intensive shared memory usage, and
understanding this can help me improve it solving some "no memory" messages.
I put the code in attach.
Thanks,
Wandenberg
Hello!
A user of mine, rvsw, reported an issue in the $args builtin variable.
Setting $args does not change the r->valid_unparsed_uri flag so
modules like ngx_proxy might still use the unparsed URI even when the
$args has been assigned to a new value.
A minimal example that can reproduce this is as follows:
server {
listen 54123;
location = /t {
return 200 "args: $args";
}
}
server {
listen 8080;
location = /t {
set $args "foo=1&bar=2";
proxy_pass http://127.0.0.1:54123;
}
}
Querying localhost:8080/t should give
args: foo=1&bar=2
But we're getting
args:
with the current nginx core.
The patch attached to this email fixes this issue.
Thanks!
-agentzh
# HG changeset patch
# User Yichun Zhang <agentzh(a)gmail.com>
# Date 1390506359 28800
# Node ID 17186b98c235c07e94c64e5853689f790f173756
# Parent 4b50d1f299d8a69f3e3f7975132e1490352642fe
Variable: setting $args should invalidate unparsed uri.
diff -r 4b50d1f299d8 -r 17186b98c235 src/http/ngx_http_variables.c
--- a/src/http/ngx_http_variables.c Fri Jan 10 11:22:14 2014 -0800
+++ b/src/http/ngx_http_variables.c Thu Jan 23 11:45:59 2014 -0800
@@ -15,6 +15,8 @@
ngx_http_variable_value_t *v, uintptr_t data);
static void ngx_http_variable_request_set(ngx_http_request_t *r,
ngx_http_variable_value_t *v, uintptr_t data);
+static void ngx_http_variable_request_args_set(ngx_http_request_t *r,
+ ngx_http_variable_value_t *v, uintptr_t data);
static ngx_int_t ngx_http_variable_request_get_size(ngx_http_request_t *r,
ngx_http_variable_value_t *v, uintptr_t data);
static void ngx_http_variable_request_set_size(ngx_http_request_t *r,
@@ -218,7 +220,7 @@
NGX_HTTP_VAR_NOCACHEABLE, 0 },
{ ngx_string("args"),
- ngx_http_variable_request_set,
+ ngx_http_variable_request_args_set,
ngx_http_variable_request,
offsetof(ngx_http_request_t, args),
NGX_HTTP_VAR_CHANGEABLE|NGX_HTTP_VAR_NOCACHEABLE, 0 },
@@ -647,6 +649,15 @@
static void
+ngx_http_variable_request_args_set(ngx_http_request_t *r,
+ ngx_http_variable_value_t *v, uintptr_t data)
+{
+ r->valid_unparsed_uri = 0;
+ ngx_http_variable_request_set(r, v, data);
+}
+
+
+static void
ngx_http_variable_request_set(ngx_http_request_t *r,
ngx_http_variable_value_t *v, uintptr_t data)
{