[jira] Commented: (COUCHDB-197) Replication renders CouchDB unresponsive.
[
https://issues.apache.org/jira/browse/COUCHDB-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667130#action_12667130
]
Jason Davies commented on COUCHDB-197:
--
I'd be interested if anyone else can reproduce any errors with the
"replication" test when using the couch_redirects.3.diff patch above. I can
reproduce strange problems on a Debian box, which look like a possible bug in
inets' http:request(). The test runs fine on my Mac OS X and Ubuntu boxes
using the same versions of Erlang. The Debian box is actually a VPS running
with smp=8 and an average load of 7, so maybe the problem only occurs under
high load. I've tried disabling smp but the problem still occurs. Here's a
sample of the kind of error I'm getting:
{"error":"{badmatch,\n{error,\n{bad_return_value,\n
{error,\n{invalid_version,\n
\"\\\"_revs\\\":[\\\"1947022206\\\"]}}\\r\\n1\\r\\n]\\r\\n0\\r\\n\\r\\nHTTP/1.1\"}","reason":"[{couch_rep,do_http_request,4},\n
{couch_rep,open_doc_revs,4},\n {couch_rep,'-enum_docs_parallel/3-fun-1-',3},\n
{couch_rep,'-spawn_worker/3-fun-0-',3}]"}
Further notes:
1. It looks like this is happening in inets' http client when it is attempting
to parse the HTTP version line, which is why I'm thinking there is some weird
concurrency issue here.
2. The other thing is that this problem *only occurs* with the patch applied,
which means there may be something wrong with http:request's handling of
301/302 redirects in a pipelined situation.
3. When I comment out the {max_pipeline_length, 101} option, the errors no
longer occur, indicating there may be a problem with pipelining.
> Replication renders CouchDB unresponsive.
> -
>
> Key: COUCHDB-197
> URL: https://issues.apache.org/jira/browse/COUCHDB-197
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
>Reporter: Maximillian Dornseif
>Priority: Blocker
> Fix For: 0.9
>
> Attachments: couch_redirects.2.diff, couch_redirects.3.diff,
> couch_redirects.diff, couch_tests.js.diff, push_replication_fix.diff
>
>
> I am quite sure this is not the same issue as in COUCHDB-193.
> Im trying to replicte a somewhat big database
> {"doc_count":541394,"doc_del_count":265692,"update_seq":2118390,"purge_seq":0,"compact_running":false,"disk_size":16552608803}
> to an other machine.
> I started replication with this:
> send: 'POST /_replicate HTTP/1.1\r\nHost:
> couchdb1.local.xxx:5984\r\nAccept-Encoding: identity\r\ncontent-length:
> 90\r\ncontent-type: application/json\r\naccept:
> application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
> send: '{"source": "hulog_events", "target":
> "http://couchdb2.local.xxx:5984/hulog_events"}'
> reply: ''
> connect: (couchdb1.local.hudora.biz, 5984)
> send: 'POST /_replicate HTTP/1.1\r\nHost:
> couchdb1.local.:5984\r\nAccept-Encoding: identity\r\ncontent-length:
> 90\r\ncontent-type: application/json\r\naccept:
> application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
> send: '{"source": "hulog_events", "target":
> "http://couchdb2.local.:5984/hulog_events"}'
> (no reply so far)
> On the source server (couchdb1) I see following logentries:
> Mon, 05 Jan 2009 19:34:21 GMT] [info] [<0.12745.45>] 192.168.0.30 - - 'POST'
> /_replicate 200
> [Mon, 05 Jan 2009 19:35:36 GMT] [info] [<0.107.0>] Compaction for db
> "hulog_events_test" completed.
> [Mon, 05 Jan 2009 19:35:45 GMT] [info] [<0.12746.45>] 127.0.0.1 - - 'GET'
> /hulog_events/ 200
> [Mon, 05 Jan 2009 19:35:46 GMT] [info] [<0.95.0>] Compaction for db "eap"
> completed.
> [Mon, 05 Jan 2009 19:42:17 GMT] [error] [<0.12765.45>] ** Generic server
> <0.12765.45> terminating
> ** Last message in was {'EXIT',<0.12762.45>,
> {timeout,
> {gen_server,call,
> [<0.12768.45>,
>{write,
> <<0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,2,
> 109,0,0,0,7,112,114,111,100,117,99,116,109,
> 0,0,0,8,54,53,49,52,48,47,69,75,104,2,109,0,
> 0,0,11,116,114,97,110,115,97,99,116,105,111,
> 110,109,0,0,0,8,114,101,116,114,105,101,118,
> 101,104,2,109,0,0,0,4,116,121,112,101,109,0,
> 0,0,4,117,110,105,116,104,2,109,0,0,0,11,97,
> 114,99,104,105,118,101,100,95,97,116,109,0,
> 0,0,22,50,48,48,56,48,50,50,50,84,49,50,49,
> 52,48,53,46,53,50,54,51,56,52,104,2,109,0,0,
> 0,10,99,114,101,97,116,101,100,95,97,116,
>
[jira] Updated: (COUCHDB-197) Replication renders CouchDB unresponsive.
[
https://issues.apache.org/jira/browse/COUCHDB-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-197:
-
Attachment: couch_redirects.3.diff
Slightly tweaked patch: better naming and removed compiler warning about unused
variable.
> Replication renders CouchDB unresponsive.
> -
>
> Key: COUCHDB-197
> URL: https://issues.apache.org/jira/browse/COUCHDB-197
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
>Reporter: Maximillian Dornseif
>Priority: Blocker
> Fix For: 0.9
>
> Attachments: couch_redirects.2.diff, couch_redirects.3.diff,
> couch_redirects.diff, couch_tests.js.diff, push_replication_fix.diff
>
>
> I am quite sure this is not the same issue as in COUCHDB-193.
> Im trying to replicte a somewhat big database
> {"doc_count":541394,"doc_del_count":265692,"update_seq":2118390,"purge_seq":0,"compact_running":false,"disk_size":16552608803}
> to an other machine.
> I started replication with this:
> send: 'POST /_replicate HTTP/1.1\r\nHost:
> couchdb1.local.xxx:5984\r\nAccept-Encoding: identity\r\ncontent-length:
> 90\r\ncontent-type: application/json\r\naccept:
> application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
> send: '{"source": "hulog_events", "target":
> "http://couchdb2.local.xxx:5984/hulog_events"}'
> reply: ''
> connect: (couchdb1.local.hudora.biz, 5984)
> send: 'POST /_replicate HTTP/1.1\r\nHost:
> couchdb1.local.:5984\r\nAccept-Encoding: identity\r\ncontent-length:
> 90\r\ncontent-type: application/json\r\naccept:
> application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
> send: '{"source": "hulog_events", "target":
> "http://couchdb2.local.:5984/hulog_events"}'
> (no reply so far)
> On the source server (couchdb1) I see following logentries:
> Mon, 05 Jan 2009 19:34:21 GMT] [info] [<0.12745.45>] 192.168.0.30 - - 'POST'
> /_replicate 200
> [Mon, 05 Jan 2009 19:35:36 GMT] [info] [<0.107.0>] Compaction for db
> "hulog_events_test" completed.
> [Mon, 05 Jan 2009 19:35:45 GMT] [info] [<0.12746.45>] 127.0.0.1 - - 'GET'
> /hulog_events/ 200
> [Mon, 05 Jan 2009 19:35:46 GMT] [info] [<0.95.0>] Compaction for db "eap"
> completed.
> [Mon, 05 Jan 2009 19:42:17 GMT] [error] [<0.12765.45>] ** Generic server
> <0.12765.45> terminating
> ** Last message in was {'EXIT',<0.12762.45>,
> {timeout,
> {gen_server,call,
> [<0.12768.45>,
>{write,
> <<0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,2,
> 109,0,0,0,7,112,114,111,100,117,99,116,109,
> 0,0,0,8,54,53,49,52,48,47,69,75,104,2,109,0,
> 0,0,11,116,114,97,110,115,97,99,116,105,111,
> 110,109,0,0,0,8,114,101,116,114,105,101,118,
> 101,104,2,109,0,0,0,4,116,121,112,101,109,0,
> 0,0,4,117,110,105,116,104,2,109,0,0,0,11,97,
> 114,99,104,105,118,101,100,95,97,116,109,0,
> 0,0,22,50,48,48,56,48,50,50,50,84,49,50,49,
> 52,48,53,46,53,50,54,51,56,52,104,2,109,0,0,
> 0,10,99,114,101,97,116,101,100,95,97,116,
> 109,0,0,0,22,50,48,48,55,49,49,50,56,84,49,
> 53,52,50,48,54,46,51,52,52,54,49,56,104,2,
> 109,0,0,0,4,112,114,111,112,104,1,108,0,0,0,
> 2,104,2,109,0,0,0,8,108,111,99,97,116,105,
> 111,110,109,0,0,0,6,65,85,83,76,65,71,104,2,
> 109,0,0,0,6,104,101,105,103,104,116,98,0,0,
> 7,158,106,104,2,109,0,0,0,3,109,117,105,109,
> 0,0,0,18,51,52,48,48,53,57,57,56,49,48,48,
> 48,48,51,49,50,53,50,104,2,109,0,0,0,8,113,
> 117,97,110,116,105,116,121,97,11,106,106>>}]}}}
> ** When Server state == {file_descriptor,prim_file,{#Port<0.904761>,24}}
> ** Reason for termination ==
> ** {timeout,{gen_server,call,
> [<0.12768.45>,
> {write,<<0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,
> 2,109,0,0,0,7,112,114,111,100,117,99,116,
> 109,0,0,0,8,54,53,49,52,48,47,69,75,104,
> 2,109,0,0,0,11,116,114,97,110,115,97,99,
> 116,105,111,110,109,0,0,0,8,114,101,116,
> 114,105,101,118,101,104,2,109,0,0,0,4,
>
[jira] Resolved: (COUCHDB-11) CouchDB should handle errors when opening port gracefully
[ https://issues.apache.org/jira/browse/COUCHDB-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-11. --- Resolution: Fixed This seems to have been fixed for a few weeks now. The failure message prints as: Failure to start Mochiweb: eaddrinuse Which is not the prettiest, but will work for any Mochiweb error. We could add a lookup table with pretty error message, but for now I think this is informative enough. > CouchDB should handle errors when opening port gracefully > - > > Key: COUCHDB-11 > URL: https://issues.apache.org/jira/browse/COUCHDB-11 > Project: CouchDB > Issue Type: Bug >Reporter: Noah Slater >Priority: Minor > > ATM CouchDB crashes loud and hard when it tries to open a port that is not > available. There should be some error handling code in place that produces > a nice message like so: > "Could not open port %d: %s" % (port_number, message) > Obviously, the above is written in Python - but you get the idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CouchDB 0.9
Nice. Thanks Paul, Jan. Adam On Jan 25, 2009, at 10:25 AM, Paul Carey wrote: Adam Try this instead http://jan.prima.de/fuckjira.html Paul On Sun, Jan 25, 2009 at 3:24 PM, Adam Kocoloski wrote: Hi Jan, I tried that link but JIRA tells me "Please select a valid filter". I wonder if you're the only one who can subscribe? Adam On Jan 24, 2009, at 8:39 AM, Jan Lehnardt wrote: Hi, Sorry for the flood :) I created a filter in JIRA that shows all blocking issues for 0.9. You can "subscribe" (whatever that means, I hope it's for you to track the matching issues) to it using this link: https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?filterId=12313005 Happy hacking, Jan --
Re: CouchDB 0.9
Adam Try this instead http://jan.prima.de/fuckjira.html Paul On Sun, Jan 25, 2009 at 3:24 PM, Adam Kocoloski wrote: > Hi Jan, I tried that link but JIRA tells me "Please select a valid filter". > I wonder if you're the only one who can subscribe? > > Adam > > On Jan 24, 2009, at 8:39 AM, Jan Lehnardt wrote: > >> Hi, >> >> Sorry for the flood :) >> >> I created a filter in JIRA that shows all blocking issues for 0.9. >> You can "subscribe" (whatever that means, I hope it's for you to >> track the matching issues) to it using this link: >> >> >> https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?filterId=12313005 >> >> Happy hacking, >> Jan >> -- > >
Re: CouchDB 0.9
Hi Jan, I tried that link but JIRA tells me "Please select a valid filter". I wonder if you're the only one who can subscribe? Adam On Jan 24, 2009, at 8:39 AM, Jan Lehnardt wrote: Hi, Sorry for the flood :) I created a filter in JIRA that shows all blocking issues for 0.9. You can "subscribe" (whatever that means, I hope it's for you to track the matching issues) to it using this link: https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?filterId=12313005 Happy hacking, Jan --
