best approach for content phase handler to run again with event timer & ngx_done?

[Maxim Dounin]

Hello!

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 
particular:

- 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.

-- 
Maxim Dounin
http://nginx.org/