[ANNOUNCE] ngx_echo v0.29: major core refactoring and more robust sequential subrequests

agentzh agentzh at gmail.com
Wed May 5 13:15:32 MSD 2010

Hi, list!

I'm happy to announce the v0.29 release of the ngx_echo module:


As mentioned in some other threads on the nginx mailing list, I've
completed the big refactoring of the ngx_echo module's core in this
version to reflect my latest understanding (hopefully being quite
complete and correct already) of the nginx internals.

Now the implementation of echo_subrequest, echo_location, echo_sleep,
and echo_read_request_body directives has been massively rewritten.
I'm trying to set up a design pattern for nginx content handlers that
require to do various kinds of non-blocking I/O during its lifetime
(similar to upstream modules but for different tasks like subrequests
and others).

For sequential subrequests issued by the echo module's content
handler, we now use a totally different approach.

Instead of issuing subrequests directly in our post_subrequest
callback (as fed into the ngx_http_subrequest call), we now postpone
firing the subrequests in a custom write event handler which will be
called automatically once the current subrequest in question gets
completely finalized (that post_subrequest callback is called by
ngx_http_finalize_request of the subrequest in question).

This works because the parent request will always be waken up once its
subrequest completes. (This is done by ngx_http_finalize_request via
posting the parent request into the "posted requests" queue and the
posted requests will be always called at the end of the top-level
read/write event handler, i.e., ngx_http_request_handler).

This solves a lot of issues like mangled r->main->count and the
following alert message when nginx is configured with the --with-debug
option, for instance,

    2010/05/05 16:46:14 [alert] 23853#0: *1 http finalize non-active
request: "/main?" ...

We'll apply this trick to the upcoming ngx_lua and ngx_srcache modules soon :)

I've Cc'd the nginx-devel mailing list because other nginx developers
might find this useful.

Stay tuned!

P.S. See the ngx_echo module's wiki page for more information:

More information about the nginx mailing list