[PATCH] ngx_gzip might hang the request for slow downstreams

[Maxim Dounin]

Hello!

On Fri, Oct 25, 2013 at 10:59:44PM -0700, Yichun Zhang (agentzh) wrote:

> Hello!
> 
> On Fri, Oct 25, 2013 at 10:55 PM, Yichun Zhang (agentzh) wrote:
> >
> > This is triggered by my own (3rd-party) module, ngx_lua. This module
> > provides a ngx.flush(true) API function that flushes out all pending
> > output data and *wait* (nonblockingly) until all outputs are *indeed*
> > flushed out (into the system socket send buffer):
> >
> >     https://github.com/chaoslawful/lua-nginx-module#ngxflush
> >
> 
> Sorry, I pressed the mail send button too fast. Below are some more details:
> 
> Under the hood, it sends out a special buf with ->flush set and then
> checks the return value of the output filter chain. If it is
> NGX_AGAIN, then wait for the next write event. Upon a new write event,
> call ngx_http_output_filter(r, NULL) to flush out the output and check
> r->connection->buffered to see if there's still any pending data.
> 
> Is this the right way to do this? If not, do you have any suggestions?

Well, it would be good to adjust gzip (and other filters) to make 
this actually work.  And I think something similar may be 
triggered using non-buffered proxy, too.  Part of a response might 
be left in buffers till new data from an upstream is received 
(despite the fact that a client is again able to recieve the data, 
and non-buffered proxy tries to flush everything as fast as 
possible).

I don't think the patch you suggested is correct though.  At least 
it lacks update chains call.  It may also make sense to look at 
the "if (ctx->nomem)" codepath, which is very similar and probably 
may be adjusted to handle this case as well.

-- 
Maxim Dounin
http://nginx.org/en/donation.html