Jesse Storimer <[email protected]> wrote:
> I've been trying to understand what happens in Unicorn when a client
> terminates a connection, and nginx logs a 499 response code.
We'd have to read the nginx sources to answer what nginx does, but
of course I can answer what Unicorn does off the top of my head.
> In my debugging this can happen if the client is on a flaky connection,
> or if they double-click a form submit button, the first request is
> terminated and nginx logs a 499 response code.
<snip> (the snipped paragraph deserves independent observation/attention)
> Can you confirm that this is actually what happens in Unicorn when the
> client disconnects? I'm not seeing anything in the logs to indicate the
> actual behaviour.
It depends on when exactly the client (nginx) disconnect is detected.
Unicorn has 4 distinct states :
1) reading headers, if a client disconnects before it has written _all_
of its request headers, the Rack app will never be called.
Since no applicaton logic fired at this point.
2) inside Rack dispatch (rack.input reading)
This will abort the Rack application dispatch if your client
disconnects before _all_ of the request body is sent. Unlike
most servers, Unicorn lazily reads any request bodies.
You can catch exceptions from env["rack.input"].{read,gets,each}
to detect this.
The Unicorn::PrereadInput middleware can minimize the time window for
this state by reading the request body ASAP.
You can also ignore this if your app isn't handling
requests with bodies (POST/PUT), but since you mentioned form
input...
3) inside Rack dispatch (after rack.input reading)
Your app has no way of knowing your client disconnected at
this stage. You can hack Unicorn to IO.select in a separate
thread, but there'll always be exposed windows leading up to
4) so it's not worth it...
4) writing the response: Unicorn will abort whenever a socket
error is detected. Keep in mind that every single part of the
Rack response array can be dynamically generated by the app.
Your application can still be "running" even though the Rack app
has returned its response for Unicorn to start writing.
Clients/Rack middleware can be written to detect this in the
response body "close" method by checking if body.each completed.
> In dealing with this I'm thinking about turning on
> proxy_ignore_client_abort
> (http://wiki.nginx.org/HttpProxyModule#proxy_ignore_client_abort) so
> that requests that make it to the Rails
> app aren't aborted. Does anyone have experience with this? I can see it
> causing its own sorts of confusion.
I've never used it.
--
Eric Wong
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
