|agentzh||May 5, 2010 2:14 am|
|Sergey A. Osokin||May 5, 2010 2:32 am|
|agentzh||May 5, 2010 2:51 am|
|agentzh||May 6, 2010 4:42 am|
|Matthieu Tourne||May 6, 2010 10:55 am|
|agentzh||May 6, 2010 6:54 pm|
|Matthieu Tourne||May 7, 2010 9:40 am|
|agentzh||May 9, 2010 8:43 pm|
|Matthieu Tourne||May 10, 2010 12:07 pm|
|peterjanovsky||May 10, 2010 1:11 pm|
|agentzh||May 10, 2010 8:08 pm|
|Subject:||[ANNOUNCE] ngx_echo v0.29: major core refactoring and more robust sequential subrequests|
|Date:||May 5, 2010 2:14:54 am|
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! -agentzh
P.S. See the ngx_echo module's wiki page for more information: http://wiki.nginx.org/NginxHttpEchoModule