Tom Burns <[email protected]> wrote: > We're looking at potential solutions to this problem, including: > - modifying unicorn to select() on the client connection after reading > the request, to see if it's been closed upstream, and avoid calling > the app.
You should be able to get the socket out of Unicorn::TeeInput/Unicorn::StreamInput object via: env["rack.input"].instance_variable_get(:@socket) Make sure you don't have other middleware which wraps rack.input such as Rack::Lint. I highly doubt the ivar name will change in the future. If you're accepting uploads, you (or your app framework) will need to drain the socket of upload data, first (Rails does this for you, I think). > - Replacing nginx with haproxy and queuing connections there. This > goes against the nginx recommendation at > http://unicorn.bogomips.org/PHILOSOPHY.html Haproxy is fine as long as you have nginx /somewhere/ in between unicorn and clients. You have some extra overhead in data copying, but it could save you cycles... I'm unsure about the ordering, however: a) nginx -> haproxy -> unicorn b) haproxy -> nginx -> unicorn Though, I suspect a) will be better. > Any input would be appreciated. I'd love to hear back on how you eventually solve this, too :> _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
