Iñaki Baz Castillo <[email protected]> wrote: > 2012/11/28 Andrew Stewart <[email protected]>: > > 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. _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
