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