[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247491#comment-15247491
 ] 

ASF GitHub Bot commented on COUCHDB-2834:
-

Github user asfgit closed the pull request at:

https://github.com/apache/couchdb-couch/pull/164


> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>Priority: Blocker
>  Labels: has-pr
> Fix For: 2.0.0
>
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247490#comment-15247490
 ] 

ASF subversion and git services commented on COUCHDB-2834:
--

Commit c4624d95e45ec4b45f7c6ddfbc4cd61413ee1d63 in couchdb-couch's branch 
refs/heads/master from [~kzx]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=c4624d9 ]

When reading attachments, avoid closing connections too early

Signal mochiweb to not send connection:close headers
in order for the socket to be reused.

Before this commit, this signaling was done too late.

COUCHDB-2834


> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>Priority: Blocker
>  Labels: has-pr
> Fix For: 2.0.0
>
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247192#comment-15247192
 ] 

ASF GitHub Bot commented on COUCHDB-2834:
-

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-couch/pull/164

When reading attachments, avoid closing connections too early

Signal mochiweb to not send connection:close headers
in order for the socket to be reused.

Before this commit, this signaling was done too late.

COUCHDB-2834

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cloudant/couchdb-couch couchdb-2834

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/couchdb-couch/pull/164.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #164


commit c4624d95e45ec4b45f7c6ddfbc4cd61413ee1d63
Author: Nick Vatamaniuc 
Date:   2016-04-19T04:59:30Z

When reading attachments, avoid closing connections too early

Signal mochiweb to not send connection:close headers
in order for the socket to be reused.

Before this commit, this signaling was done too late.

COUCHDB-2834




> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>Priority: Blocker
>  Labels: has-pr
> Fix For: 2.0.0
>
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[Nick Vatamaniuc (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247182#comment-15247182
 ] 

Nick Vatamaniuc commented on COUCHDB-2834:
--

Just noticed email from JIRA. Will have PR ready by tomorrow.

> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>Priority: Blocker
>  Labels: has-pr
> Fix For: 2.0.0
>
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[Robert Newson (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246617#comment-15246617
 ] 

Robert Newson commented on COUCHDB-2834:


noting that this should not prevent replication working.

> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>Priority: Blocker
>  Labels: has-pr
> Fix For: 2.0.0
>
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[Alexander Shorin (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976331#comment-14976331
 ] 

Alexander Shorin commented on COUCHDB-2834:
---

Marking this blocker since it makes unable to replicate from any of 1.x version 
to 2.0.

> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Nick Vatamaniuc
>Priority: Blocker
> Fix For: 2.0.0
>
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943660#comment-14943660
 ] 

ASF GitHub Bot commented on COUCHDB-2834:
-

Github user nickva commented on the pull request:


https://github.com/apache/couchdb-couch-replicator/pull/19#issuecomment-145599470
  
@rnewson @davisp @kxepal 

When processing the request we set mochiweb_request_recv = true in the 
process dictionary too late. That makes it return Connection: close. ibrowse 
used to ignore Connection: close and just kept the socket open. Then ibrowse 
was fixed and revealed the issue.

Here is a potential fix and the details: 
https://issues.apache.org/jira/browse/COUCHDB-2834 


> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Nick Vatamaniuc
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[Nick Vatamaniuc (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941367#comment-14941367
 ] 

Nick Vatamaniuc commented on COUCHDB-2834:
--

Some experiments with curl. 

Command below creates a database "db",  PUTs two attachments to x/a and y/a.  
Connection is reused across 3 requests in same curl command. Wireshark also 
confirms. Script below runs in 2 TCP sessions. First is the delete command and 
rest is a single session ( - some strange packet length sizes and duplicate ack 
warnings).

{code}
DB='http://127.0.0.1:15984/db'
CTYPE="Content-Type: application/octet-stream"
curl -u testuser:testpass -X DELETE $DB
curl -v -u testuser:testpass -X PUT $DB --next \
 -v -u testuser:testpass -H "Expect:" -H "$CTYPE" -X PUT --data-binary @2m 
"$DB/x/a" --next \
 -v -u testuser:testpass -H "Expect:" -H "$CTYPE" -X PUT --data-binary @2m 
"$DB/y/a"

{"ok":true}
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 15984 (#0)
* Server auth using Basic with user 'testuser'
> PUT /db HTTP/1.1
> Host: 127.0.0.1:15984
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 201 Created
< Cache-Control: must-revalidate
< Content-Length: 12
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 02 Oct 2015 16:41:10 GMT
< Location: http://127.0.0.1:15984/db
< Server: CouchDB/4ca9e41 (Erlang OTP/17)
< X-Couch-Request-ID: 6bad671c4b
< X-CouchDB-Body-Time: 0
<
{"ok":true}
* Connection #0 to host 127.0.0.1 left intact
* Found bundle for host 127.0.0.1: 0x7fd53240c7a0
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 15984 (#0)
* Server auth using Basic with user 'testuser'
> PUT /db/x/a HTTP/1.1
> Host: 127.0.0.1:15984
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 200
>
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Cache-Control: must-revalidate
< Content-Length: 64
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 02 Oct 2015 16:41:11 GMT
< Location: http://127.0.0.1:15984/db/x/a
< Server: CouchDB/4ca9e41 (Erlang OTP/17)
< X-Couch-Request-ID: b88b70b811
< X-CouchDB-Body-Time: 0
<
{"ok":true,"id":"x","rev":"1-7219667ca52a862e8d0d21498e68f7d3"}
* Connection #0 to host 127.0.0.1 left intact
* Found bundle for host 127.0.0.1: 0x7fd53240c7a0
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 15984 (#0)
* Server auth using Basic with user 'testuser'
> PUT /db/y/a HTTP/1.1
> Host: 127.0.0.1:15984
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 200
>
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Cache-Control: must-revalidate
< Content-Length: 64
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 02 Oct 2015 16:41:11 GMT
< Location: http://127.0.0.1:15984/db/y/a
< Server: CouchDB/4ca9e41 (Erlang OTP/17)
< X-Couch-Request-ID: 75a614dca9
< X-CouchDB-Body-Time: 0
<
{"ok":true,"id":"y","rev":"1-7219667ca52a862e8d0d21498e68f7d3"}
* Connection #0 to host 127.0.0.1 left intact

{code}

> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Nick Vatamaniuc
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2834) Server sends connection: close too early

[Nick Vatamaniuc (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941414#comment-14941414
 ] 

Nick Vatamaniuc commented on COUCHDB-2834:
--

Another experiment. Setting an invalid Content-Length on the request make 
server block for at least 10+ seconds. Then returns with a 500 Error 
{"error":"unknown_error","reason":"undefined"} and connect is closed.

{code}
#!/bin/sh
DB='http://127.0.0.1:15984/db'
CTYPE="Content-Type: application/octet-stream"
curl -u testuser:testpass -X DELETE $DB
curl -v -u testuser:testpass -X PUT $DB --next \
 -v -u testuser:testpass -H "Expect:" -H "$CTYPE" -X PUT --data-binary @2m 
-H "Content-Length: 999" "$DB/x/a" --next \
 -v -u testuser:testpass -H "Expect:" -H "$CTYPE" -X PUT --data-binary @2m 
"$DB/y/a"


{"ok":true}
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 15984 (#0)
* Server auth using Basic with user 'testuser'
> PUT /db HTTP/1.1
> Host: 127.0.0.1:15984
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 201 Created
< Cache-Control: must-revalidate
< Content-Length: 12
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 02 Oct 2015 17:04:04 GMT
< Location: http://127.0.0.1:15984/db
< Server: CouchDB/4ca9e41 (Erlang OTP/17)
< X-Couch-Request-ID: 0824cbfdef
< X-CouchDB-Body-Time: 0
<
{"ok":true}
* Connection #0 to host 127.0.0.1 left intact
* Found bundle for host 127.0.0.1: 0x7fb3cc901730
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 15984 (#0)
* Server auth using Basic with user 'testuser'
> PUT /db/x/a HTTP/1.1
> Host: 127.0.0.1:15984
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 999
>
* We are completely uploaded and fine
< HTTP/1.1 500 Internal Server Error
< Cache-Control: must-revalidate
< Connection: close
< Content-Length: 47
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 02 Oct 2015 17:05:04 GMT
< Server: CouchDB/4ca9e41 (Erlang OTP/17)
< X-Couch-Request-ID: 7409bb037f
< X-CouchDB-Body-Time: 0
<
{"error":"unknown_error","reason":"undefined"}
* Closing connection 0
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 15984 (#1)
* Server auth using Basic with user 'testuser'
> PUT /db/y/a HTTP/1.1
> Host: 127.0.0.1:15984
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 200
>
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Cache-Control: must-revalidate
< Content-Length: 64
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 02 Oct 2015 17:05:04 GMT
< Location: http://127.0.0.1:15984/db/y/a
< Server: CouchDB/4ca9e41 (Erlang OTP/17)
< X-Couch-Request-ID: 16743bb3a4
< X-CouchDB-Body-Time: 0
<
{"ok":true,"id":"y","rev":"1-7219667ca52a862e8d0d21498e68f7d3"}
* Connection #1 to host 127.0.0.1 left intact

{code}


> Server sends connection: close too early
> 
>
> Key: COUCHDB-2834
> URL: https://issues.apache.org/jira/browse/COUCHDB-2834
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Nick Vatamaniuc
>
> This is related COUCHDB-2833.
> This was found investigating the failure of replication tests. Specifically 
> couch_replicator_large_atts_tests, the {local, remote} sub-case.
> The test sets up push replications from local to remote.
> Replication workers  have more than 1 document larger than 
> MAX_BULK_ATT_SIZE=64K.  They start pushing them to the target, using a 
> keep-alive connection (default  for HTTP 1.1), the first few pipelined 
> requests will go through using the same connection, then server will accept 
> the first PUT to …/docid?edits=false, then return Connection:close and close 
> the connection after the 201 Created result.  
> Server should not close request too early and instead keep it open longer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)