Re: Backwards compatibility
On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau bchesn...@gmail.com wrote: Your probably right about the user migrations. Basically if your use document doesn't have any owner doc a normal user won't be abble to update it. On the other hand it should still be possible to update/delete them with an admin. Can ou create separate issues about this on jira ? (one for migration , and the other for the users db migration) ? It will help to track the problem. Sorry, not sure what you mean here. Cheers, Dirkjan
website jira
The website should have a direct link to jira on top so anyone can click on it to easily report an issue. - benoît
Re: website jira
agreed. Another thing we seemed to have lost on the new site is an easy way to link to the API references on the WIKI. Perhaps Documentation could be another top level category -- Bob On Apr 10, 2012, at 9:37 AM, Benoit Chesneau wrote: The website should have a direct link to jira on top so anyone can click on it to easily report an issue. - benoît
[jira] [Created] (COUCHDB-1461) replication timeout and loop
replication timeout and loop
Key: COUCHDB-1461
URL: https://issues.apache.org/jira/browse/COUCHDB-1461
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2, 1.3
Reporter: Benoit Chesneau
Attachments: test.py
When you try to do at the same time a replication in both way, it will timeout
then restart after 5s. Sometimes it won't be able to recover well. Adding a
sleep between 2 reps is possibly solving it but it shouldn't be needed.
Attached is a script using couchdbkit to reproduce the problem. SERVER_URI need
to be changed to point to your couchdb node.
Log:
09:09:24.016 [info] 127.0.0.1 - - HEAD /testdb1/ 404
09:09:24.028 [info] 127.0.0.1 - - PUT /testdb1/ 201
09:09:24.033 [info] 127.0.0.1 - - HEAD /testdb2/ 404
09:09:24.046 [info] 127.0.0.1 - - PUT /testdb2/ 201
09:09:24.071 [info] 127.0.0.1 - - GET
/_replicator/_all_docs?include_docs=true 200
09:09:28.110 [info] 127.0.0.1 - - PUT /_replicator/rep1 201
09:09:28.119 [info] 127.0.0.1 - - PUT /_replicator/rep2 201
09:09:28.121 [info] Attempting to start replication
`23280770e617f3a82f398b8eca09aaef` (document `rep1`).
09:09:28.123 [info] Attempting to start replication
`e42aaea4a0ceb931930834ecf7b79600` (document `rep2`).
09:09:28.169 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:09:28.172 [info] 127.0.0.1 - - GET /testdb2/ 200
09:09:28.176 [info] 127.0.0.1 - - GET
/testdb2/_local/e42aaea4a0ceb931930834ecf7b79600 404
09:09:28.179 [info] 127.0.0.1 - - GET
/testdb2/_local/f129a5531f82eb089a3e1ca9e80c9ad2 404
09:09:28.194 [info] Replication `e42aaea4a0ceb931930834ecf7b79600` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:09:28.196 [info] 127.0.0.1 - - GET
/testdb2/_changes?feed=normalstyle=all_docssince=0heartbeat=1
200
09:09:28.202 [info] Document `rep2` triggered replication
`e42aaea4a0ceb931930834ecf7b79600`
09:09:28.203 [info] starting new replication
`e42aaea4a0ceb931930834ecf7b79600` at 0.262.0
(`http://localhost:15984/testdb2/` - `testdb1`)
09:09:28.208 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:09:28.212 [info] 127.0.0.1 - - GET /testdb2/ 200
09:09:28.218 [info] 127.0.0.1 - - GET
/testdb2/_local/23280770e617f3a82f398b8eca09aaef 404
09:09:28.219 [info] Replication `e42aaea4a0ceb931930834ecf7b79600`
finished (triggered by document `rep2`)
09:09:28.223 [info] 127.0.0.1 - - GET
/testdb2/_local/4b04e1e066f4ad1f988669036080ed9c 404
09:09:28.225 [info] Replication `23280770e617f3a82f398b8eca09aaef` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:09:58.203 [error] gen_server 0.287.0 terminated with reason: killed
09:09:58.207 [error] CRASH REPORT Process 0.287.0 with 0 neighbours
crashed with reason:
{killed,[{gen_server,terminate,6,[{file,gen_server.erl},{line,737}]},{proc_lib,init_p_do_apply,3,[{file,proc_lib.erl},{line,227}]}]}
09:09:58.215 [error] Error in replication
`23280770e617f3a82f398b8eca09aaef` (triggered by document `rep1`):
timeout
Restarting replication in 5 seconds.
09:10:03.223 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:10:03.227 [info] 127.0.0.1 - - GET /testdb2/ 200
09:10:03.231 [info] 127.0.0.1 - - GET
/testdb2/_local/23280770e617f3a82f398b8eca09aaef 404
09:10:03.235 [info] 127.0.0.1 - - GET
/testdb2/_local/4b04e1e066f4ad1f988669036080ed9c 404
09:10:03.237 [info] Replication `23280770e617f3a82f398b8eca09aaef` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:10:03.244 [info] Document `rep1` triggered replication
`23280770e617f3a82f398b8eca09aaef`
09:10:03.245 [info] starting new replication
`23280770e617f3a82f398b8eca09aaef` at 0.335.0 (`testdb1` -
`http://localhost:15984/testdb2/`)
09:10:03.253 [info] Replication `23280770e617f3a82f398b8eca09aaef`
finished (triggered by document `rep1`)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1461) replication timeout and loop
[
https://issues.apache.org/jira/browse/COUCHDB-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau updated COUCHDB-1461:
-
Attachment: test.py
replication timeout and loop
Key: COUCHDB-1461
URL: https://issues.apache.org/jira/browse/COUCHDB-1461
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2, 1.3
Reporter: Benoit Chesneau
Attachments: test.py
When you try to do at the same time a replication in both way, it will
timeout then restart after 5s. Sometimes it won't be able to recover well.
Adding a sleep between 2 reps is possibly solving it but it shouldn't be
needed.
Attached is a script using couchdbkit to reproduce the problem. SERVER_URI
need to be changed to point to your couchdb node.
Log:
09:09:24.016 [info] 127.0.0.1 - - HEAD /testdb1/ 404
09:09:24.028 [info] 127.0.0.1 - - PUT /testdb1/ 201
09:09:24.033 [info] 127.0.0.1 - - HEAD /testdb2/ 404
09:09:24.046 [info] 127.0.0.1 - - PUT /testdb2/ 201
09:09:24.071 [info] 127.0.0.1 - - GET
/_replicator/_all_docs?include_docs=true 200
09:09:28.110 [info] 127.0.0.1 - - PUT /_replicator/rep1 201
09:09:28.119 [info] 127.0.0.1 - - PUT /_replicator/rep2 201
09:09:28.121 [info] Attempting to start replication
`23280770e617f3a82f398b8eca09aaef` (document `rep1`).
09:09:28.123 [info] Attempting to start replication
`e42aaea4a0ceb931930834ecf7b79600` (document `rep2`).
09:09:28.169 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:09:28.172 [info] 127.0.0.1 - - GET /testdb2/ 200
09:09:28.176 [info] 127.0.0.1 - - GET
/testdb2/_local/e42aaea4a0ceb931930834ecf7b79600 404
09:09:28.179 [info] 127.0.0.1 - - GET
/testdb2/_local/f129a5531f82eb089a3e1ca9e80c9ad2 404
09:09:28.194 [info] Replication `e42aaea4a0ceb931930834ecf7b79600` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:09:28.196 [info] 127.0.0.1 - - GET
/testdb2/_changes?feed=normalstyle=all_docssince=0heartbeat=1
200
09:09:28.202 [info] Document `rep2` triggered replication
`e42aaea4a0ceb931930834ecf7b79600`
09:09:28.203 [info] starting new replication
`e42aaea4a0ceb931930834ecf7b79600` at 0.262.0
(`http://localhost:15984/testdb2/` - `testdb1`)
09:09:28.208 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:09:28.212 [info] 127.0.0.1 - - GET /testdb2/ 200
09:09:28.218 [info] 127.0.0.1 - - GET
/testdb2/_local/23280770e617f3a82f398b8eca09aaef 404
09:09:28.219 [info] Replication `e42aaea4a0ceb931930834ecf7b79600`
finished (triggered by document `rep2`)
09:09:28.223 [info] 127.0.0.1 - - GET
/testdb2/_local/4b04e1e066f4ad1f988669036080ed9c 404
09:09:28.225 [info] Replication `23280770e617f3a82f398b8eca09aaef` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:09:58.203 [error] gen_server 0.287.0 terminated with reason: killed
09:09:58.207 [error] CRASH REPORT Process 0.287.0 with 0 neighbours
crashed with reason:
{killed,[{gen_server,terminate,6,[{file,gen_server.erl},{line,737}]},{proc_lib,init_p_do_apply,3,[{file,proc_lib.erl},{line,227}]}]}
09:09:58.215 [error] Error in replication
`23280770e617f3a82f398b8eca09aaef` (triggered by document `rep1`):
timeout
Restarting replication in 5 seconds.
09:10:03.223 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:10:03.227 [info] 127.0.0.1 - - GET /testdb2/ 200
09:10:03.231 [info] 127.0.0.1 - - GET
/testdb2/_local/23280770e617f3a82f398b8eca09aaef 404
09:10:03.235 [info] 127.0.0.1 - - GET
/testdb2/_local/4b04e1e066f4ad1f988669036080ed9c 404
09:10:03.237 [info] Replication `23280770e617f3a82f398b8eca09aaef` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:10:03.244 [info] Document `rep1` triggered replication
`23280770e617f3a82f398b8eca09aaef`
09:10:03.245 [info] starting new replication
`23280770e617f3a82f398b8eca09aaef` at 0.335.0 (`testdb1` -
`http://localhost:15984/testdb2/`)
09:10:03.253 [info] Replication `23280770e617f3a82f398b8eca09aaef`
finished (triggered by document `rep1`)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Backwards compatibility
On Tue, Apr 10, 2012 at 08:54, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Apr 10, 2012 at 6:47 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau bchesn...@gmail.com wrote: Your probably right about the user migrations. Basically if your use document doesn't have any owner doc a normal user won't be abble to update it. On the other hand it should still be possible to update/delete them with an admin. Can ou create separate issues about this on jira ? (one for migration , and the other for the users db migration) ? It will help to track the problem. Sorry, not sure what you mean here. the ml isn't really the right way to report an issue. opening a ticket is definitely better. It helps to tracks achievements. You mean like badges??!?!?
Re: Backwards compatibility
On Tue, Apr 10, 2012 at 10:15 AM, Randall Leeds randall.le...@gmail.com wrote: On Tue, Apr 10, 2012 at 08:54, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Apr 10, 2012 at 6:47 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau bchesn...@gmail.com wrote: Your probably right about the user migrations. Basically if your use document doesn't have any owner doc a normal user won't be abble to update it. On the other hand it should still be possible to update/delete them with an admin. Can ou create separate issues about this on jira ? (one for migration , and the other for the users db migration) ? It will help to track the problem. Sorry, not sure what you mean here. the ml isn't really the right way to report an issue. opening a ticket is definitely better. It helps to tracks achievements. You mean like badges??!?!? achievement: the act of achieving : accomplishment but this idea of badges is interesting ;) - benoît
[jira] [Created] (COUCHDB-1462) Add Sharing / Reporting of CLI test results for further analysis
Add Sharing / Reporting of CLI test results for further analysis Key: COUCHDB-1462 URL: https://issues.apache.org/jira/browse/COUCHDB-1462 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Jan Lehnardt The browser based tests allowed to submit test results to a shared CouchDB instance, the CLI JS tests in 1.3/master don't do that yet. Also the etap tests don't do that either -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
(perceived) barriers to entry
After chatting with Noah S on Twitter, I offered to jot up some thoughts on things that my reduce or eliminate perceived barriers to entry to work on CouchDB. Here are a few things that I've been able to think of. In the course of researching this mail though, I've actually answered many of my own questions. serious business A database seems like the kind of project that only extremely talented people would touch. People depend on the code working. Getting started would require quite a bit of confidence. Am I good enough? Erlang, wtf This is a barrier that I've been facing for a while. I'm actually in the process of learning Erlang, trying to expand my horizons from Python. Still, a new language makes it harder to have the required confidence. I still don't understand rereduce I'm personally not 100% clear on how queries work. This is even after using the db for a while. I don't want to look like a stupid idiot in front of great developers. Therefore, there's a high risk of offering suggestions and getting told to RTFM Where are the easy bugs? [solved] wow, big code base Is there any documentation on how to project is laid out? Stepping into a new project is always a little daunting. Apache project? As someone outside of the ASF, I don't really know what contributing on an Apache project means.
Re: (perceived) barriers to entry
Hi Tim, I'm a new comer that want to but haven't contributed yet. Where are the easy bugs? Thanks, Tim On Tue, Apr 10, 2012 at 5:46 PM, Tim McNamara paperl...@timmcnamara.co.nzwrote: After chatting with Noah S on Twitter, I offered to jot up some thoughts on things that my reduce or eliminate perceived barriers to entry to work on CouchDB. Here are a few things that I've been able to think of. In the course of researching this mail though, I've actually answered many of my own questions. serious business A database seems like the kind of project that only extremely talented people would touch. People depend on the code working. Getting started would require quite a bit of confidence. Am I good enough? Erlang, wtf This is a barrier that I've been facing for a while. I'm actually in the process of learning Erlang, trying to expand my horizons from Python. Still, a new language makes it harder to have the required confidence. I still don't understand rereduce I'm personally not 100% clear on how queries work. This is even after using the db for a while. I don't want to look like a stupid idiot in front of great developers. Therefore, there's a high risk of offering suggestions and getting told to RTFM Where are the easy bugs? [solved] wow, big code base Is there any documentation on how to project is laid out? Stepping into a new project is always a little daunting. Apache project? As someone outside of the ASF, I don't really know what contributing on an Apache project means.
Re: (perceived) barriers to entry
If you visit JIRA's Issue Navigator (https://issues.apache.org/jira/secure/IssueNavigator.jspa), then select CouchDB in the project field and Easy in the skill field. Direct link at [1]. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+COUCHDB+AND+resolution+%3D+Fixed+AND+%22Skill+Level%22+%3D+%22New+Contributors+Level+%28Easy%29%22 On 11 April 2012 13:06, Timothy Chen tnac...@gmail.com wrote: Hi Tim, I'm a new comer that want to but haven't contributed yet. Where are the easy bugs? Thanks, Tim On Tue, Apr 10, 2012 at 5:46 PM, Tim McNamara paperl...@timmcnamara.co.nzwrote: After chatting with Noah S on Twitter, I offered to jot up some thoughts on things that my reduce or eliminate perceived barriers to entry to work on CouchDB. Here are a few things that I've been able to think of. In the course of researching this mail though, I've actually answered many of my own questions. serious business A database seems like the kind of project that only extremely talented people would touch. People depend on the code working. Getting started would require quite a bit of confidence. Am I good enough? Erlang, wtf This is a barrier that I've been facing for a while. I'm actually in the process of learning Erlang, trying to expand my horizons from Python. Still, a new language makes it harder to have the required confidence. I still don't understand rereduce I'm personally not 100% clear on how queries work. This is even after using the db for a while. I don't want to look like a stupid idiot in front of great developers. Therefore, there's a high risk of offering suggestions and getting told to RTFM Where are the easy bugs? [solved] wow, big code base Is there any documentation on how to project is laid out? Stepping into a new project is always a little daunting. Apache project? As someone outside of the ASF, I don't really know what contributing on an Apache project means.
Re: (perceived) barriers to entry
Btw, there was an intro to couchdb dev wiki/course before and it's here: http://moodle.wohmart.com/login/index.php The course stopped in mid-way because of both students and instructor lack of participating, but the reources I believe are still available if you want to learn more erlang and some couchdb internals. Tim On Tue, Apr 10, 2012 at 6:15 PM, Tim McNamara paperl...@timmcnamara.co.nzwrote: If you visit JIRA's Issue Navigator (https://issues.apache.org/jira/secure/IssueNavigator.jspa), then select CouchDB in the project field and Easy in the skill field. Direct link at [1]. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+COUCHDB+AND+resolution+%3D+Fixed+AND+%22Skill+Level%22+%3D+%22New+Contributors+Level+%28Easy%29%22 On 11 April 2012 13:06, Timothy Chen tnac...@gmail.com wrote: Hi Tim, I'm a new comer that want to but haven't contributed yet. Where are the easy bugs? Thanks, Tim On Tue, Apr 10, 2012 at 5:46 PM, Tim McNamara paperl...@timmcnamara.co.nzwrote: After chatting with Noah S on Twitter, I offered to jot up some thoughts on things that my reduce or eliminate perceived barriers to entry to work on CouchDB. Here are a few things that I've been able to think of. In the course of researching this mail though, I've actually answered many of my own questions. serious business A database seems like the kind of project that only extremely talented people would touch. People depend on the code working. Getting started would require quite a bit of confidence. Am I good enough? Erlang, wtf This is a barrier that I've been facing for a while. I'm actually in the process of learning Erlang, trying to expand my horizons from Python. Still, a new language makes it harder to have the required confidence. I still don't understand rereduce I'm personally not 100% clear on how queries work. This is even after using the db for a while. I don't want to look like a stupid idiot in front of great developers. Therefore, there's a high risk of offering suggestions and getting told to RTFM Where are the easy bugs? [solved] wow, big code base Is there any documentation on how to project is laid out? Stepping into a new project is always a little daunting. Apache project? As someone outside of the ASF, I don't really know what contributing on an Apache project means.
Re: (perceived) barriers to entry
On Tue, Apr 10, 2012 at 5:46 PM, Tim McNamara paperl...@timmcnamara.co.nz wrote: [snip] I still don't understand rereduce I'm personally not 100% clear on how queries work. This is even after using the db for a while. I don't want to look like a stupid idiot in front of great developers. Therefore, there's a high risk of offering suggestions and getting told to RTFM Try this: http://blog.mudynamics.com/wp-content/uploads/2009/04/icouch.html K. --- http://blitz.io @k0ws1k
