Re: When a client terminates a connection

From: Andrew Stewart <boss@airbladesoftware.com>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: When a client terminates a connection
Date: Fri, 30 Nov 2012 10:15:17 +0100	[thread overview]
Message-ID: <C2EED9ED-8503-4E99-AA38-CDFCDBED0BDF@airbladesoftware.com> (raw)
In-Reply-To: <20121129230408.GA2618@dcvr.yhbt.net>

On 30 Nov 2012, at 00:04, Eric Wong wrote:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> 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).

On the three occasions I've had this problem it's been a tiny request.

The user clicks an ordinary Rails delete link.  This POSTs to a URL with two parameters: an authenticity token and the _method.

The corresponding destroy action looks like:

    def destroy
      client = Client.find params[:id]  # 1  (ignores soft-deleted records)
      client.soft_delete                # 2  (sets a deleted_at timestamp)
      client.brands.each(&:destroy)     # 3  (a client has many brands)
      redirect_to clients_path
    end

Nginx logged:

    x.xxx.xx.xx - - [27/Nov/2012:14:40:28 +0000] "POST /clients/2248 HTTP/1.1" 499 0 "https://example.com/clients/2248/edit" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
    x.xxx.xx.xx - - [27/Nov/2012:14:40:29 +0000] "POST /clients/2248 HTTP/1.1" 404 592 "https://example.com/companies/2248/edit" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"

You can see the first request was terminated by the user.  Hot on its heels the user tried again and got a 404.

The 404 was triggered by step 1 above: the first request had successfully soft-deleted the client.  However the client's brands were still in the database.  The first request had executed steps 1 and 2 but not step 3.

Unicorn didn't log anything.  Rails didn't log the first request but did log the second.

I understand the steps to mitigate the problem...but I remain confused about why the Rails app was interrupted because the TCP connection was closed prematurely.

Yours,
Andrew Stewart
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying