Request hangs

Hi,

I have strange problem with main request hand if I call for
sub-request. Maybe somebody can help me with it?

I do spam filtering in post request. So I added location to nginx.conf
and call sub-request for that location. Then read output from
sub-request and set up nginx variable according to output.

So config looks like:
location = /checkspam {
internal;
include spam_fastcgi.conf;
}

SOURCE code is here:
http://codepaste.net/17tfmu

From client side it looks like client can not receive last chank of
original request (last 10-50 bytes). And it’s not easy to understand
what is going on. Any advises are welcome.

I put debug log here:
http://codepaste.net/ceiian

Thanks,
Max.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,178511,178511#msg-178511

magz Wrote:

From client side it looks like client can not
receive last chank of original request (last 10-50
bytes). And it’s not easy to understand what is
going on. Any advises are welcome.

I put debug log here:
http://codepaste.net/ceiian

Thanks,
Max.

Silence here means that question was not clear or nobody knows the
answer. I will try to ask my question in another way. If you know the
answer please respond to me.

I do:

  1. register handler in REWRITE_PHASE
    h = ngx_array_push(&cmcf->phases[NGX_HTTP_REWRITE_PHASE].handlers);
    *h = ngx_http_form_input_handler;

  2. In ngx_http_form_input_handler() read POST body and act the
    handler:
    r->request_body_in_single_buf = 1;
    rc = ngx_http_read_client_request_body(r,
    ngx_http_form_input_post_read);

  3. In ngx_http_form_input_post_read() call subsequent with POST body to
    different location
    psr->handler = ngx_http_form_input_post_subrequest_handler;
    rc = ngx_http_subrequest(r, &uri, &args, &sr, psr, 0);

Now the question is why original request hands on returning last buffer
chank to client?

It looks like client holds on read() forever. If kill signal is sent to
nginx client receives this last buffer. Also sub-request works fine
(send all POST data from client and receives what is should receive).
Without sub-request everything works fine too.

Is it know nginx issue?

What workaround can be applied here? Maybe create create additional
filter and terminate request? Or adjust request buffers after
sub-request is done?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,178511,179019#msg-179019

On Mon, Feb 28, 2011 at 2:33 PM, magz [email protected] wrote:

magz Wrote:

Hi,

I have strange problem with main request hand if
I call for sub-request. Maybe somebody can help
me with it?

Which version of nginx are you using?

If you’re using nginx 0.8.x and above, the symptom suggests you didn’t
get r->main->count right. Use --with-debug while building your nginx,
and track the values of r->main->count.

For example, in the following line of my local error.log,

2011/01/28 13:01:50 [debug] 1199#0: *1 http finalize request: -4,

“/main?” a:0, c:3

a:0 means the current request is not the active request at the moment
(i.e., r != r->connection->data), and c:3 means r->main->count is 3.
The request can only be successfully finalized unless it is the
current active request. Also, the main request won’t terminate, i.e.,
will hang if the r->main->count counter is not going to be decremented
to zero. Well, r->main->count is just a reference counter for the main
request object. A simple way of doing poors’ “garbage collection”,
well, at least kind of.

When doing subrequest programming on the C level, one should be VERY
VERY careful with these two values, among other things :slight_smile:

Cheers,
-agentzh

agentzh Wrote:

help

r->main->count is 3.
well, at least kind of.
nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx

Thanks for the hint agentzh! Will try to dig in that area.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,178511,179039#msg-179039

r->count–; to the right place fixed my problem.

Thanks agentzh again!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,178511,179222#msg-179222

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs