Michael Fischer <[email protected]> wrote: > On Tue, Mar 24, 2015 at 10:59 PM, Eric Wong <[email protected]> wrote: > > Another likely explanation might be you're not draining rack.input every > > request, since unicorn does lazy reads off the socket to prevent > > rejected uploads from wasting disk I/O[1] > > > > So you can send a bigger POST request with my example to maybe > > reproduce the issue. > > > > [1] you can use the Unicorn::PrereadInput middleware to forcibly > > disable the lazy read: > > http://unicorn.bogomips.org/Unicorn/PrereadInput.html > > Actually, these are quite large POST requests we're attempting to > service (on the order of 4MB). Can you elaborate on the mechanism in > play here?
Unlike a lot of servers, unicorn will not attempt to buffer request bodies on its own. You'll need to actually process the POST request in your app (via Rack/Rails/whatever accessing env["rack.input"]). The PrereadInput middleware makes it behave like other servers (at the cost of being slower if a request is worthless and rejected) So there might be data sitting on the socket if your application processing returns a response before it parsed the POST request. In this case, the ECONNRESET messages are harmless and saves your Ruby process from GC thrashing. Actually, you can try setting up a Rack::Lobster instance but sending a giant POST request? ------------- config.ru -------------- require 'rack/lobster' run Rack::Lobster.new --------------------------------------
