best approach for content phase handler to run again with event timer & ngx_done?
mdounin at mdounin.ru
Mon Jun 2 16:26:57 UTC 2014
On Fri, May 30, 2014 at 02:27:36PM -0700, bfranks781 at gmail.com wrote:
> If a content phase handler needs to wait on some potentially delayed
> result, my understanding is that it should return NGX_DONE so that it is
> called again.
> I've been reading through the eval, echo, and http_limit_req modules to see
> how to integrate an nginx_add_timer event prior to returning NGX_DONE. A
> short timer event seems reasonable, because the content phase handler isn't
> waiting on some other event type (subrequest result, timeout, etc). The
> timer event seems fairly straight-forward -- configure the event in a
> request context and set the event handler, data and log.
> I don't really want my timer event handler to do anything -- rather I just
> want the same content phase handler that had previously returned NGX_DONE
> to run again. In that case, should my timer event handler actually do
> anything at all? Is there a best practice for this -- i.e. have it point
> to the write_event_handler(), call ngx_http_core_run_phases() or
> ngx_http_run_posted_requests(), etc?
A content phase handler will not be called again (or at least it's
not supposed to). If a content phase handler returns NGX_DONE, it
means that it's responsible for further request handling, in
- you've already done proper request reference counting tweaks
(normally, by just calling ngx_http_read_client_request_body(),
which will do r->count++);
- you are responsible for sending a response and then finalizing
the request with ngx_http_finalize_request().
Modules based on the ngx_http_upstream.c (most simple one is
memcached) are examples of content handlers which return NGX_DONE.
More information about the nginx-devel