terminate a connection after sending headers

Maxim Dounin mdounin at mdounin.ru
Fri Sep 5 04:35:16 UTC 2014


On Thu, Sep 04, 2014 at 04:38:41PM -0400, erankor2 wrote:

> Thank you very much Maxim ! this works !
> However, I bumped into a new problem, I use 2 different types of asyncronous
> operations in my code - file I/O and http requests. When I call
> ngx_http_run_posted_requests from the aio callback it works well, but when I
> call it from the HTTP completion callback it actually makes the request
> hang. 
> I can see that it calls ngx_http_upstream_check_broken_connection in
> r->write_event_handler(r). I guess that in this case I should let
> ngx_http_run_posted_requests run from the upstream module instead of calling
> it myself.
> So my questions are:
> 1. Is there a simple rule that dictates when I should call
> ngx_http_run_posted_requests and when I should not ? 
> I can work around the problem by doing something like 'if called from the
> aio callback call ngx_http_run_posted_requests' otherwise, don't call, but
> that doesn't feel like the correct solution. 

You should call ngx_http_run_posted_requests() after low-level 
events.  That is, there is no need to call it after http-related 
events, as ngx_http_run_posted_requests() will be called by 
ngx_http_request_handler().  But if your own low-level events are 
triggered, like the timer in your code, it's your responsibility 
to call ngx_http_request_handler() after them.

> 2. A simpler solution that seems to work for me, is to call
> ngx_http_run_posted_requests only when I see that r->main->count is one
> (before finalize). But I don't know if that solution makes any sense - is
> there any relation between these posted_requests and the request count ? 

No, it doesn't make sense to check r->main->count.

> My understanding (before reading your reply :)) was that whenever I do
> something asynchronous I must increment the count, whenever I call
> finalize_request the count is decremented and once the count reaches zero
> the request is terminated. So, what I'm missing is why the termination of
> the request has to be deferred via posted requests - couldn't
> ngx_http_terminate_request just close the request only when it sees the
> count reached zero instead ?

Termination on errors which you are doing isn't expected to wait 
for r->main->count to reach zero.  It is expected to proactively 
stop all ongoing activity by executing cleanup handlers, and then 
free the request.

Maxim Dounin

More information about the nginx mailing list