Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <3502196.80591289246107388.JavaMail.jira@thor>
Date: Mon, 8 Nov 2010 14:55:07 -0500 (EST)
From: "Filipe Manana (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Closed: (COUCHDB-682) Transfer-Encoding: chunked causes
 improper keepalive behaviour
In-Reply-To: <1058173789.82641267740331732.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filipe Manana closed COUCHDB-682.
---------------------------------

    Resolution: Won't Fix

> Transfer-Encoding: chunked causes improper keepalive behaviour
> --------------------------------------------------------------
>
>                 Key: COUCHDB-682
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-682
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 0.10.1, 0.11
>         Environment: couchdbx 0.10.0 on OS X 10.5.x, and svn rev 919046 (current HEAD of 0.11.x branch) under ubuntu 9.x
>            Reporter: Chas Emerick
>            Assignee: Filipe Manana
>         Attachments: couchdbdump.libpcap, put_reuse_tcp_connection.escript
>
>
> When using chunked transfer encoding with clutch (a clojure couchdb client lib and view server), I've found that read timeouts on PUTs are highly reliable on the second consecutive request to a couch instance.
> I dug around, and discovered (after sniffing the traffic) that what was manifesting as a read timeout from the JDK's http client was actually the connection being closed by couch, instead of being kept alive.  The java http client is likely attempting to read from a dead connection, but it's not quite smart enough to realize it.  Note that this *only* happens when chunked transfer encoding is enabled.
> A simple test with curl appears to reinforce my hypothesis (transcript at the bottom of this msg): notice the "Connection #0 seems to be dead" messages -- looks like curl is a lot more graceful about re-establishing the lost connection than the JDK's http client is.
> ** Note that this requires two files to be uploaded at from /tmp/foo1 and /tmp/foo2
> [catapult:~] chas% curl -X DELETE http://localhost:5984/chunkedtest ; curl -X PUT http://localhost:5984/chunkedtest ; curl -v -T "/tmp/foo[1-2]" -H "Transfer-Encoding: chunked" http://localhost:5984/chunkedtest/
> {"error":"not_found","reason":"missing"}
> {"ok":true}
> * About to connect() to localhost port 5984 (#0)
> *   Trying ::1... Connection refused
> *   Trying fe80::1... Connection refused
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > PUT /chunkedtest/foo1 HTTP/1.1
> > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> > Host: localhost:5984
> > Accept: */*
> > Transfer-Encoding: chunked
> > Expect: 100-continue
> > 
> < HTTP/1.1 100 Continue
> < HTTP/1.1 201 Created
> < Server: CouchDB/0.10.0 (Erlang OTP/R13B)
> < Location: http://localhost:5984/chunkedtest/foo1
> < Etag: "1-5b9bf8556d9846a224332d3f7435fd89"
> < Date: Thu, 04 Mar 2010 22:01:40 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 67
> < Cache-Control: must-revalidate
> < 
> {"ok":true,"id":"foo1","rev":"1-5b9bf8556d9846a224332d3f7435fd89"}
> * Connection #0 to host localhost left intact
> * Connection #0 seems to be dead!
> * Closing connection #0
> * About to connect() to localhost port 5984 (#0)
> *   Trying ::1... Connection refused
> *   Trying fe80::1... Connection refused
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > PUT /chunkedtest/foo2 HTTP/1.1
> > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> > Host: localhost:5984
> > Accept: */*
> > Transfer-Encoding: chunked
> > Expect: 100-continue
> > 
> < HTTP/1.1 100 Continue
> < HTTP/1.1 201 Created
> < Server: CouchDB/0.10.0 (Erlang OTP/R13B)
> < Location: http://localhost:5984/chunkedtest/foo2
> < Etag: "1-5b9bf8556d9846a224332d3f7435fd89"
> < Date: Thu, 04 Mar 2010 22:01:40 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 67
> < Cache-Control: must-revalidate
> < 
> {"ok":true,"id":"foo2","rev":"1-5b9bf8556d9846a224332d3f7435fd89"}
> * Connection #0 to host localhost left intact
> * Closing connection #0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.