terminate a connection after sending headers
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
> 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.
More information about the nginx