terminate a connection after sending headers

[Maxim Dounin]

Hello!

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
http://nginx.org/