"Eric Wong" <[email protected]> said:
> Jimmy Soho <[email protected]> wrote: >> fwiw, we experience this too irregularly, about once a week or 2 weeks >> for a few seconds, and sometimes up to a minute or 2 minutes long. for >> no apparent reasons indeed. and at random times. > > Wait, based on what you say below, is this happening to unicorn or > nginx? > >> my suspicion so far has always been that this is due to bad (wifi) >> networks of clients. what happens when a request is handled >> successfully by rails, but for whatever reason the last bit of the >> response can't be delivered because the receiving end is not consuming >> in a timely fashion? > > So nginx is complaining about disconnected clients, not unicorn, > correct? > >> If i'm not mistaken i think that rails logs a 200 success message >> before the response is actually send back? > > Correct, rails/unicorn won't know if the client disconnected until > nginx breaks the connection to unicorn. > >> Is a response send back by rails / unicorn fully buffered by nginx? Or >> is a unicorn worker blocked until the response is confirmed to have >> been successfully received by the client? > > nginx fully buffers both requests and responses by default. > Which leads us to... > >> Aside: how do you protect your unicorn workers against a barrage of >> client requests that eat the response veeeeeery sloooooooowly? > > That's the whole point of using nginx with unicorn. nginx shields > unicorn from slow clients. Is it possible that the behavior could be related to nginx? Nginx hanging onto the connection too long from the worker, so that the worker never makes it back into the pool and eventually get's killed for not checking in? _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
