Hi,
On Sun, Jul 14, 2013 at 12:40 AM, Yichun Zhang (agentzh) <agen...@gmail.com>wrote: > Hello! > > On Sat, Jul 13, 2013 at 4:43 PM, Julien Zefi wrote: > > > > I have been trying many workarounds without luck, the last one that i > have > > is that if in my timer-callback the flush returns NGX_AGAIN, invoke a new > > handler that sends out an empty chain, but it continue returning > NGX_AGAIN, > > it never backs to NGX_OK, this is how it looks: > > > > It seems that what you're doing is very wrong. You'd better take a > look at how the ngx_http_writer and ngx_http_set_write_handler > functions are implemented in the Nginx core instead of shooting in the > darkness. Basically: > > 1. Flush outputs by r->write_event_handler instead of in your timer > handler because you should only retry sending the outputs upon a > epoll/poll/select write event. > > 2. By "sending out an empty chain", I actually mean > > rc = ngx_http_output_filter(r, NULL); > > You can see this line in the ngx_http_writer function. You're just > sending out a last_buf chain. > > Sorry by bother you again but i still cannot figure out how some internals are not working as i expect. I have take in count your suggestions and wrote a new test case (file attached). My goal in that test case is to let NginX invoke my write_event_handler once the socket is ready to write again when a NGX_AGAIN is found, despite the test case is not perfect for all things that need to be fixed, i have isolated as much as i can. The test case writes 12.3KB of data every 1ms, at some point it will raise NGX_AGAIN but from there is not recovering, it keeps in the same state forever, do you see any specific problem when handling the exception ? thnks
test_case_02.tar.gz
Description: GNU Zip compressed data
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
