You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Chas Emerick (JIRA)" <ji...@apache.org> on 2010/03/04 23:05:31 UTC
[jira] Created: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
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
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.
[jira] Updated: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Paul Joseph Davis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Joseph Davis updated COUCHDB-682:
--------------------------------------
Skill Level: Regular Contributors Level (Easy to Medium)
> 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
> Attachments: couchdbdump.libpcap
>
>
> 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.
[jira] Commented: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Chas Emerick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841654#action_12841654 ]
Chas Emerick commented on COUCHDB-682:
--------------------------------------
The first two curl invocations are just a DELETE and PUT on the test db itself -- just so as to make the command easily repeatable, avoid the 409's. The third curl invocation, if I'm understanding the semantics of specifying glob patterns to -T with a "directory" url, should be producing a single connection, with keepalive, over which all specified PUTs are made.
Anyway, I'm attaching a libpcap dump of the traffic captured in the course of a read timeout with the java stack. Turning off chunked transfers eliminates the error.
> 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
>
> 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.
[jira] Commented: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Jerome Louvel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928850#action_12928850 ]
Jerome Louvel commented on COUCHDB-682:
---------------------------------------
I'd like to confirm the issue. We reproduced it using our Restlet HTTP client.
If CouchDB can't initially support persistent connections after chunked encoded request entities, maybe it should at least make it explicit using the "Connection: close" HTTP header.
> 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
> Attachments: couchdbdump.libpcap
>
>
> 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.
[jira] Commented: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Paul Joseph Davis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841568#action_12841568 ]
Paul Joseph Davis commented on COUCHDB-682:
-------------------------------------------
Your shell command is invoking curl multiple times which is going to prevent that connection from being reused.
Can you provide a trace of the HTTP traffic that leads up to the timeout?
> 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
>
> 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.
[jira] Commented: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928961#action_12928961 ]
Filipe Manana commented on COUCHDB-682:
---------------------------------------
I'll look into it soon.
> 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
>
>
> 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.
[jira] Commented: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Chas Emerick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929707#action_12929707 ]
Chas Emerick commented on COUCHDB-682:
--------------------------------------
I'm *thrilled* that this has finally been replicated by others (I had essentially assumed I'd lost my mind), and that it's already fixed in a forthcoming version of couch. Thank you very much.
> 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.
[jira] Assigned: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana reassigned COUCHDB-682:
-------------------------------------
Assignee: Filipe Manana
> 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
>
>
> 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.
[jira] Updated: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana updated COUCHDB-682:
----------------------------------
Attachment: put_reuse_tcp_connection.escript
Ok, so I was able to verify that the Mochiweb version shipped with CouchDB 1.0.x and earlier versions closes the connection (after receiving a PUT document with a chunked transfer encoding).
CouchDB trunk (from which 1.1.x will be based) has a more recent version of Mochiweb, which doesn't close the connection.
With the following Erlang script, I can use the same TCP connection to send 10000 consecutive document PUT requests (all of them using chunked transfer encoding). Each document has a size of about 90Kb.
I'll consider this ticket closed.
> 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.
[jira] Updated: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Chas Emerick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chas Emerick updated COUCHDB-682:
---------------------------------
Attachment: couchdbdump.libpcap
libpcap dump of java stack's TCP traffic leading up to read timeout
> 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
> Attachments: couchdbdump.libpcap
>
>
> 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.
[jira] Closed: (COUCHDB-682) Transfer-Encoding: chunked causes
improper keepalive behaviour
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ 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.