When a client terminates a connection

Eric Wong normalperson at yhbt.net
Thu Nov 29 23:04:08 UTC 2012

Iñaki Baz Castillo <ibc at aliax.net> wrote:
> 2012/11/28 Andrew Stewart <boss at airbladesoftware.com>:
> > 1. Client clicks a delete link in my webapp.
> > 2. Rails starts processing the appropriate destroy action.  This updates various things in the database (but not in a single db transaction).
> > 3. Client terminates the connection.
> > 4. Rails stops executing the destroy action wherever it has got to, leaving the latter part of the action unexecuted and my db inconsistent.
> > 5. Rails and Unicorn don't write anything to their logs; Nginx writes a 499.
> Hi, I've read the thread and understood that there is solutions or
> workarounds for this issue. However I don't understand why this issue
> does exist. There should be no relationship between the TCP connection
> and the request processing:
> - If the request has been entirely received, the process it entirely, period.
> - If later the response cannot be sent due to connection closed, then
> ok, the response cannot be sent, period.
> I don't understand why the application on top of the HTTP/TCP layer
> (so the Rails app) should be interrupted because the TCP connection is
> closed prematurely. The HTTP layer (which involves a single TCP
> connection for each HTTP request/response pair) is a layer below the
> application layer, should not disturb the Rails app IMHO.
> Is this a design issue of Rails?

I suspect the the only possibility is when Rails is reading the
multipart response in a largish upload (any upload request which
can't fit in socket buffers).

Perhaps Andrew can enlighten us further.

More information about the mongrel-unicorn mailing list