[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688319#action_12688319
]
Chris Anderson commented on COUCHDB-270:
This concords with the current state of COUCHDB-163: pull replication is binary
streaming, push replication still uses base64. I believe that the groundwork
has been laid for this, it's just a matter of closing the loop in the
replicator.
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py, couchdb270_Test.py, quick_fix.diff
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,114,
> 101,118,
> 115,61,116,
> 114,117,
> 101,38,97,
> 116,116,97,
> 99,104,109,
> 101,110,
> 116,115,61,
> 116,114,
> 117,101,38,
>
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682076#action_12682076
]
Jeff Hinrichs commented on COUCHDB-270:
---
All of the large document tests are passing. All of the proper attachment pull
tests, 10,12,14,16,18 work just fine. However the proper attachment push tests
(13,15,17) still fail if the attachments are of any size. (#11 passes -
200x256K payload + 256K Attachment) I start getting connection refused errors
with those.
Sorry for the tardiness of my reply. Was out of town in SF, I ran the tests as
soon as I got back, it took a while to figure out what was going on since the
pushes left couch in a bad state and then the rest of the tests would fail.
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py, couchdb270_Test.py, quick_fix.diff
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,114,
> 101,118,
> 115,61,116,
> 114,117,
> 101,38,97,
> 116,116,97,
> 99,104,109,
>
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682077#action_12682077
]
Jeff Hinrichs commented on COUCHDB-270:
---
forgot to mention on the last report: Apache CouchDB 0.9.0a752084
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py, couchdb270_Test.py, quick_fix.diff
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,114,
> 101,118,
> 115,61,116,
> 114,117,
> 101,38,97,
> 116,116,97,
> 99,104,109,
> 101,110,
> 116,115,61,
> 116,114,
> 117,101,38,
> 108,97,116,
> 101,115,
>
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679904#action_12679904
]
Adam Kocoloski commented on COUCHDB-270:
Hi Jeff, those longer-term fixes have landed on trunk. I checked that all of
the tests you posted passed on machines with 2GB or more of memory. To reduce
the memory consumption further we need to dig into the ibrowse HTTP client that
Couch uses internally.
Do you mind confirming that the tests pass in your environment?
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py, couchdb270_Test.py, quick_fix.diff
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,114,
> 101,118,
> 115,61,116,
> 114,117,
> 101,38,97,
> 116,116,97,
> 99,104,109,
> 101,110,
> 116,115,61,
> 116,114,
>
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678336#action_12678336
]
Adam Kocoloski commented on COUCHDB-270:
Hi Jeff, tests for attachments would be nice. In the trunk code they should
perform essentially the same as the test with a document of a similar size, but
eventually we'll be handling attachments differently (i.e. streaming them
directly to disk, see COUCHDB-163).
I've done some testing with large numbers of revisions on my own -- I don't
think we need to add any more tests to this ticket. The replicator already
knows to split up a request if the # of revs is so large that they can't all
fit into an 8KB URL (MochiWeb limit). I don't believe there are any other
gotchas related to large numbers of revisions. The replicator only grabs the
latest one, after all.
Cheers, Adam
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py, quick_fix.diff
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,114,
> 101,118,
> 115,61,116,
> 114,117,
> 101,38,97,
> 116,116
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678323#action_12678323
]
Jeff Hinrichs commented on COUCHDB-270:
---
Adam, I am reproducing the similar results in my environment (laptop).
Although, with less memory??, neither 20M is passing for me.
200x20m push FAIL (connection refused)
200x20m pull FAIL
Thank you for your work on this.
Now that you are getting closer, should I update the tests to use proper
attachments in addition to extremely large documents? If so, I was thinking
tests for documents with a 512K body size +:
* one massive attachment (20MB)
* three attachments (10M/6M/4M) 20M overall in attachments
* a dozen attachments (5M/5M/10x1M) 20M overall in attachments
If you would like different/additional tests/parameters let me know and I'll
update the script to include them.
Now that I am on my second cup of joe, I should probably do a test that focuses
on a large number of revisions. Currently the tests create databases that are
relatively pristine with N revisions, where N is 0 or very small. If you would
like this in the tests what N or Ns should be used?
Jeff
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py, quick_fix.diff
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,114,
> 101,118,
>
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678231#action_12678231
]
Adam Kocoloski commented on COUCHDB-270:
Hi Jeff, thanks for the test case -- it proved quite useful. I have a
short-term fix and a longer-term solution. I'll attach the quick fix now (still
waiting on SVN commit access). It merely sets the ibrowse timeout to infinity
and does a better check of the memory utilization when deciding whether to
flush the save_docs_buffer.
The longer term solution will likely require scrapping the parallelized portion
of the replicator. Processing 100 documents in parallel doesn't give us enough
control over the memory utilization on the servers. I'm confident I can rewrite
the module so that it loads documents into memory "just-in-time" and maintains
the same throughput with a much lower memory footprint.
I ran your test suite between two m1.large instances on EC2 and got the
following results:
200x512k push OK
200x512k pull OK
200x1m push OK
200x1m pull OK
200x20m push OK
200x20m pull FAIL
The last one failed in "head shot" fashion -- I believe the target server
Erlang VM ran out of memory. Fixing that one will require the long-term
solution. Will keep you posted,
Adam
> Replication w/ Large Attachments Fails
> --
>
> Key: COUCHDB-270
> URL: https://issues.apache.org/jira/browse/COUCHDB-270
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: Apache CouchDB 0.9.0a748379
>Reporter: Jeff Hinrichs
> Attachments: couchdb270_Test.py
>
>
> Attempting to replicate a database with largish attachments (<= ~18MB of
> attachments in a doc, less thatn 200 docs) from one machine to another fails
> consistently and at the same point.
> Scenario:
> Both servers are running from HEAD and I've been tracking for some time.
> This problem has been around as long as I've been using couch.
> Machine A holds the original database, Machine B is the server that is doing
> a PULL replication
> During the replication, Machine A starts showing the following sporadically
> in the log:
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5902.3>] 'GET'
> /delasco-invoices/INV00652429?revs=true&attachments=true&latest=true&open_revs=["425644723"]
> {1,
> 1}
> Headers: [{'Host',"192.168.2.52:5984"}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [error] [<0.5901.3>] Uncaught error in
> HTTP request: {exit,normal}
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] Stacktrace:
> [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_db,db_doc_req,3},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,3},
> {mochiweb_http,headers,5},
> {proc_lib,init_p,5}]
> [Fri, 27 Feb 2009 14:02:48 GMT] [debug] [<0.5901.3>] HTTPd 500 error response:
> {"error":"error","reason":"normal"}
> As the replication continues, the frequency of these error "Uncaught error in
> HTTP request: {exit,normal}" increase. Until the error is being constantly
> repeated. Then Machine B stops sending requests, no more log output, no
> errors, the last thing in Machine B's log file is:
> [Fri, 27 Feb 2009 14:03:24 GMT] [info] [<0.20893.1>] retrying
> couch_rep HTTP get request due to {error, req_timedout}: [104,116,
> 116,112,58,
> 47,47,49,
> 57,50,46,
> 49,54,56,
> 46,50,46,
> 53,50,58,
> 53,57,56,
> 52,47,100,
> 101,108,97,
> 115,99,111,
> 45,105,110,
> 118,111,
> 105,99,101,
> 115,47,73,
> 78,86,48,
> 48,54,53,
> 50,49,51,
> 56,63,
[jira] Commented: (COUCHDB-270) Replication w/ Large Attachments Fails
[
https://issues.apache.org/jira/browse/COUCHDB-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677694#action_12677694
]
Jeff Hinrichs commented on COUCHDB-270:
---
The above failure was created using futon.
I am trying to build a script to replicate the failure on demand but I am
seeing something different now, the error is kind of like couchdb-240 (see
below for more error output) I will attach my script to this issue. Hopefully
it will help.
--error information---
[Sat, 28 Feb 2009 16:56:35 GMT] [info] [<0.962.0>] 192.168.2.52 - - 'POST'
/couchdb-270-target/_bulk_docs 201
[Sat, 28 Feb 2009 16:56:49 GMT] [debug] [<0.979.0>] 'POST'
/couchdb-270-target/_bulk_docs {1,1}
Headers: [{'Host',"192.168.2.194:5984"},
{'Transfer-Encoding',"chunked"}]
[Sat, 28 Feb 2009 16:57:18 GMT] [error] [<0.906.0>] ** Generic server <0.906.0>
terminating
** Last message in was {update_docs,[[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[],[],[],[],[],[],[]],
[]}
** When Server state == {db,<0.905.0>,<0.906.0>,nil,<<"1235840109444771">>,
<0.904.0>,<0.908.0>,
{db_header,0,100,
{104867784,0},
{104876441,{100,0}},
{104872023,100},
nil,0,nil,nil},
{stream,<0.907.0>,<0.904.0>},
{btree,<0.904.0>,
{104876441,{100,0}},
#Fun,
#Fun,
#Fun,
#Fun},
{btree,<0.904.0>,
{104872023,100},
#Fun,
#Fun,
#Fun,
#Fun},
{btree,<0.904.0>,nil,
#Fun,
#Fun,
#Fun,nil},
100,<<"couchdb-270-target">>,
"/usr/local/var/lib/couchdb/couchdb-270-target.couch",
[],[],nil,
{user_ctx,null,[]},
nil}
** Reason for termination ==
** {function_clause,
[{couch_db_updater,'-update_docs_int/3-fun-0-',[[],{[],[]}]},
{lists,foldl,3},
{couch_db_updater,update_docs_int,3},
{couch_db_updater,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p,5}]}
[Sat, 28 Feb 2009 16:57:19 GMT] [error] [<0.906.0>] {error_report,<0.22.0>,
{<0.906.0>,crash_report,
[[{pid,<0.906.0>},
{registered_name,[]},
{error_info,
{exit,
{function_clause,
[{couch_db_updater,'-update_docs_int/3-fun-0-',
[[],{[],[]}]},
{lists,foldl,3},
{couch_db_updater,update_docs_int,3},
{couch_db_updater,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p,5}]},
[{gen_server,terminate,6},{proc_lib,init_p,5}]}},
{initial_call,
{gen,init_it,
[gen_server,<0.905.0>,<0.905.0>,couch_db_updater,
{<0.905.0>,<<"couchdb-270-target">>,
"/usr/local/var/lib/couchdb/couchdb-270-target.couch",
<0.904.0>,
[create,{user_ctx,{user_ctx,null,[<<"_admin">>]}}]},
[]]}},
{ancestors,
[<0.905.0>,couch_server,couch_primary_services,
couch_server_sup,<0.1.0>]},
{messages,[]},
{links,[<0.905.0>,<0.907.0>]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,6765},
{stack_size,23},
{reductions,96260}],
[{neighbour,
[{pid,<0.907.0>},
{registered_name,[]},
{initial_call,
{gen,init_it,
[gen_server,<0.906.0>,<0.906.0>,couch_stream,
{{0,0},<0.904.0>},
[]]}},
{current_function,{gen_server,loop,6}},
{ancestors,
[<0.906.0>,<0.905.0>,couch_server,couch_prim
