[jira] [Created] (COUCHDB-1158) Log server crashes when view contains unicode and log level is set to debug
Log server crashes when view contains unicode and log level is set to debug --- Key: COUCHDB-1158 URL: https://issues.apache.org/jira/browse/COUCHDB-1158 Project: CouchDB Issue Type: Bug Components: Database Core Environment: OSX, Built from Git - 1.2.0a8a37632-git Reporter: Dale Harvey When a document contains a simple unicode escaped character and the log level is set to debug, running any view over the document crashes the log server http://pastebin.me/883abdacdb3feca6b4ed965413091458 will investigate further -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1157) Replication of test results DB in Futon test suite is broken
[
https://issues.apache.org/jira/browse/COUCHDB-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Cottlehuber updated COUCHDB-1157:
--
Attachment: fix_futon_test_suite_reports.patch
patched against trunk, but should be applied to 1.0.x and 1.1.x as well -
simple fix.
Needs confirmation that the new URL is the correct one.
> Replication of test results DB in Futon test suite is broken
>
>
> Key: COUCHDB-1157
> URL: https://issues.apache.org/jira/browse/COUCHDB-1157
> Project: CouchDB
> Issue Type: Bug
> Components: Futon
>Reporter: Dave Cottlehuber
>Priority: Minor
> Labels: futon, testsuite
> Fix For: 1.0.3, 1.1
>
> Attachments: fix_futon_test_suite_reports.patch
>
>
> Futon test suite points to couchdb.couchdb.org but this no longer accepts
> replication or responds as a couch. Presumably this is some front end proxy
> rewrite issue since the merger, as couchdb.couchone.com or iriscouch.com
> works.
> This patch repoints directly to iriscouch.com.
> dave@akai:~/source/couchdb/trunk $ dig couchdb.couchdb.org
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> couchdb.couchdb.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12846
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;couchdb.couchdb.org. IN A
> ;; ANSWER SECTION:
> couchdb.couchdb.org.83598 IN CNAME couchdb.couchone.com.
> couchdb.couchone.com. 798 IN A 184.73.200.44
> ;; Query time: 50 msec
> ;; SERVER: 192.168.1.254#53(192.168.1.254)
> ;; WHEN: Wed May 11 14:50:15 2011
> ;; MSG SIZE rcvd: 87
> dave@akai:~/source/couchdb/trunk $ curl couchdb.couchone.com:5984
> {"couchdb":"Welcome","version":"1.0.2"}
> dave@akai:~/source/couchdb/trunk $ curl couchdb.couchone.com:5984/_all_dbs
> ["test","wiki","_users","test_suite_reports"]
> dave@akai:~/source/couchdb/trunk $ curl couchdb.couchdb.org:5984/_all_dbs
> Host not found
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1157) Replication of test results DB in Futon test suite is broken
Replication of test results DB in Futon test suite is broken
Key: COUCHDB-1157
URL: https://issues.apache.org/jira/browse/COUCHDB-1157
Project: CouchDB
Issue Type: Bug
Components: Futon
Reporter: Dave Cottlehuber
Priority: Minor
Fix For: 1.0.3, 1.1
Attachments: fix_futon_test_suite_reports.patch
Futon test suite points to couchdb.couchdb.org but this no longer accepts
replication or responds as a couch. Presumably this is some front end proxy
rewrite issue since the merger, as couchdb.couchone.com or iriscouch.com works.
This patch repoints directly to iriscouch.com.
dave@akai:~/source/couchdb/trunk $ dig couchdb.couchdb.org
; <<>> DiG 9.6.0-APPLE-P2 <<>> couchdb.couchdb.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12846
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;couchdb.couchdb.org. IN A
;; ANSWER SECTION:
couchdb.couchdb.org.83598 IN CNAME couchdb.couchone.com.
couchdb.couchone.com. 798 IN A 184.73.200.44
;; Query time: 50 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Wed May 11 14:50:15 2011
;; MSG SIZE rcvd: 87
dave@akai:~/source/couchdb/trunk $ curl couchdb.couchone.com:5984
{"couchdb":"Welcome","version":"1.0.2"}
dave@akai:~/source/couchdb/trunk $ curl couchdb.couchone.com:5984/_all_dbs
["test","wiki","_users","test_suite_reports"]
dave@akai:~/source/couchdb/trunk $ curl couchdb.couchdb.org:5984/_all_dbs
Host not found
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tips for getting past test suite errors
Thanks, Paul. I'm using FF4.0.1 from my win7 machine to hit Futon.
One error seems to be triggered here in attachments.js:
var xhr = CouchDB.request("PUT", "/test_suite_db/bin_doc5/lorem.txt", {
headers:{"Content-Type":"text/plain;charset=utf-8"},
body:lorem
});
T(xhr.status == 201);
The actual status coming back is a 304 (Not Modified). But let me
give the etap tests a shot.
Some more basic questions: should I generally be working against trunk
or a different branch? Is it helpful for me to try to get the tests
all working (i.e. JIRA issues filed, with patches), or is that a
waste?
On Tue, May 10, 2011 at 9:23 PM, Paul Davis wrote:
> Jake,
>
> What browser are you using? Officially we only support FF3.5 (unless
> that version changed recently?) but the tests generally work on all
> the WebKit browsers as well though occasionally they get out of whack
> and someone eventually gets pissed and fixes them so we don't have to
> run FF.
>
> Beyond that it looks like your environment is up to snuff. I'd expect
> many more failures if not. The last error I think is an on purpose one
> which just says your SM is a bit old. The others I've not heard
> reports of or seen myself though its been awhile since I've run the
> Futon tests on trunk.
>
> Also, for tests there's also the etap tests which you can run using
> `make check` that might also point at an error somewhere.
>
> Paul
>
> On Tue, May 10, 2011 at 5:09 PM, Jake Levirne wrote:
>> Hello-
>>
>> I'm new to couchdb-dev and am trying to get to the point where I can
>> make useful contributions. Right now 8 of my tests are failing when I
>> run the test suite in futon (details below).
>>
>> I'm running on an Ubuntu 10.04.2 Server virtualbox, and I've forked
>> and cloned apache/couchdb on github and am up to date with
>> git.apache.org/couchdb.git (so I think I have the latest trunk).
>>
>> I've followed these instructions for running couchdb in dev mode:
>> http://wiki.apache.org/couchdb/Running%20CouchDB%20in%20Dev%20Mode
>>
>> and I believe all my dependencies are in order (I was able to
>> bootstrap, configure, and build successfully). Are these errors
>> expected? If not, any pointers for how to get started tracking down
>> what might be wrong with my setup?
>>
>> basics success 14232ms
>> all_docs success 6441ms
>> attachments error 5699ms
>>
>> Run with debugger
>> Assertion failed: xhr.responseText == lorem
>> Exception raised: {"message":"actual is
>> null","fileName":"http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0","lineNumber":322,"stack":"TEqualsIgnoreCase(\"text/plain;charset=utf-8\",null)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:322\u000a(false)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:147\u000arun(0)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:91\u000a"}
>>
>> attachments_multipart success 4498ms
>> attachment_names success 1643ms
>> attachment_paths success 3852ms
>> attachment_ranges success 3046ms
>> attachment_views success 2370ms
>> auth_cache success 16065ms
>> batch_save success 67251ms
>> bulk_docs success 4190ms
>> changes success 19200ms
>> compact success 11128ms
>> config success 4686ms
>> conflicts success 2191ms
>> content_negotiation success 1253ms
>> cookie_auth success 12960ms
>> copy_doc success 2367ms
>> delayed_commits success 25500ms
>> design_docs success 40423ms
>> design_options success 2835ms
>> design_paths success 3316ms
>> erlang_views success 5132ms
>> etags_head failure 2012ms
>>
>> Run with debugger
>> Assertion failed: xhr.status == 304
>>
>> etags_views success 12380ms
>> form_submit success 558ms
>> http success 1980ms
>> invalid_docids success 1386ms
>> jsonp success 2227ms
>> large_docs success 1504ms
>> list_views failure 6230ms
>>
>> Run with debugger
>> Assertion 'xhr.status == 200, "standard get should be 200"'
>> failed: standard get should be 200
>> Assertion failed: /head0123456789tail/.test(xhr.responseText)
>>
>> lots_of_docs success 1329ms
>> method_override success 1730ms
>> multiple_rows success 2342ms
>> oauth success 15701ms
>> proxyauth success 5462ms
>> purge success 8323ms
>> reader_acl success 11426ms
>> recreate_doc success 10891ms
>> reduce success 38180ms
>> reduce_builtin failure 50824ms
>>
>> Run with debugger
>> Assertion failed: db.info().doc_count == (i - 1) * 10 * 11 + (j + 1) * 11
>>
>> reduce_false success 1184ms
>> reduce_false_temp success 1171ms
>> replication success 554998ms
>> replicator_db failure 137115ms
>>
>> Run with debugger
>> Assertion failed: typeof repDoc2._replication_state === "undefined"
>> Assertion failed: typeof repDoc2._replication_state_time === "undefined"
>>
>> rev_stemming failure 10205ms
>>
>> Run with debugger
>> Assertion failed: db.open("bar
Re: Tips for getting past test suite errors
Jake,
What browser are you using? Officially we only support FF3.5 (unless
that version changed recently?) but the tests generally work on all
the WebKit browsers as well though occasionally they get out of whack
and someone eventually gets pissed and fixes them so we don't have to
run FF.
Beyond that it looks like your environment is up to snuff. I'd expect
many more failures if not. The last error I think is an on purpose one
which just says your SM is a bit old. The others I've not heard
reports of or seen myself though its been awhile since I've run the
Futon tests on trunk.
Also, for tests there's also the etap tests which you can run using
`make check` that might also point at an error somewhere.
Paul
On Tue, May 10, 2011 at 5:09 PM, Jake Levirne wrote:
> Hello-
>
> I'm new to couchdb-dev and am trying to get to the point where I can
> make useful contributions. Right now 8 of my tests are failing when I
> run the test suite in futon (details below).
>
> I'm running on an Ubuntu 10.04.2 Server virtualbox, and I've forked
> and cloned apache/couchdb on github and am up to date with
> git.apache.org/couchdb.git (so I think I have the latest trunk).
>
> I've followed these instructions for running couchdb in dev mode:
> http://wiki.apache.org/couchdb/Running%20CouchDB%20in%20Dev%20Mode
>
> and I believe all my dependencies are in order (I was able to
> bootstrap, configure, and build successfully). Are these errors
> expected? If not, any pointers for how to get started tracking down
> what might be wrong with my setup?
>
> basics success 14232ms
> all_docs success 6441ms
> attachments error 5699ms
>
> Run with debugger
> Assertion failed: xhr.responseText == lorem
> Exception raised: {"message":"actual is
> null","fileName":"http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0","lineNumber":322,"stack":"TEqualsIgnoreCase(\"text/plain;charset=utf-8\",null)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:322\u000a(false)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:147\u000arun(0)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:91\u000a"}
>
> attachments_multipart success 4498ms
> attachment_names success 1643ms
> attachment_paths success 3852ms
> attachment_ranges success 3046ms
> attachment_views success 2370ms
> auth_cache success 16065ms
> batch_save success 67251ms
> bulk_docs success 4190ms
> changes success 19200ms
> compact success 11128ms
> config success 4686ms
> conflicts success 2191ms
> content_negotiation success 1253ms
> cookie_auth success 12960ms
> copy_doc success 2367ms
> delayed_commits success 25500ms
> design_docs success 40423ms
> design_options success 2835ms
> design_paths success 3316ms
> erlang_views success 5132ms
> etags_head failure 2012ms
>
> Run with debugger
> Assertion failed: xhr.status == 304
>
> etags_views success 12380ms
> form_submit success 558ms
> http success 1980ms
> invalid_docids success 1386ms
> jsonp success 2227ms
> large_docs success 1504ms
> list_views failure 6230ms
>
> Run with debugger
> Assertion 'xhr.status == 200, "standard get should be 200"'
> failed: standard get should be 200
> Assertion failed: /head0123456789tail/.test(xhr.responseText)
>
> lots_of_docs success 1329ms
> method_override success 1730ms
> multiple_rows success 2342ms
> oauth success 15701ms
> proxyauth success 5462ms
> purge success 8323ms
> reader_acl success 11426ms
> recreate_doc success 10891ms
> reduce success 38180ms
> reduce_builtin failure 50824ms
>
> Run with debugger
> Assertion failed: db.info().doc_count == (i - 1) * 10 * 11 + (j + 1) * 11
>
> reduce_false success 1184ms
> reduce_false_temp success 1171ms
> replication success 554998ms
> replicator_db failure 137115ms
>
> Run with debugger
> Assertion failed: typeof repDoc2._replication_state === "undefined"
> Assertion failed: typeof repDoc2._replication_state_time === "undefined"
>
> rev_stemming failure 10205ms
>
> Run with debugger
> Assertion failed: db.open("bar", {revs:
> true})._revisions.ids.length == newLimit + 1
> Assertion failed: db.open("bar", {revs:
> true})._revisions.ids.length == newLimit + 1
>
> rewrite success 7711ms
> security_validation success 26567ms
> show_documents success 9692ms
> stats failure 43987ms
>
> Run with debugger
> Assertion 'triggered, "We managed to force a all_dbs_active
> error."' failed: We managed to force a all_dbs_active error.
>
> update_documents success 5215ms
> users_db success 4339ms
> utf8 success 3098ms
> uuids success 2186ms
> view_collation success 13409ms
> view_collation_raw success 7263ms
> view_conflicts success 2533ms
> view_compaction success 5684ms
> view_errors success 7816ms
> view_include_docs success 7203ms
> view
[jira] [Commented] (COUCHDB-1156) Futon shows apache license when performing unauthorised operations
[ https://issues.apache.org/jira/browse/COUCHDB-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031480#comment-13031480 ] Dale Harvey commented on COUCHDB-1156: -- A screenshot of the issue http://dropup.net/4hwjez-71c54c.png.html > Futon shows apache license when performing unauthorised operations > -- > > Key: COUCHDB-1156 > URL: https://issues.apache.org/jira/browse/COUCHDB-1156 > Project: CouchDB > Issue Type: Bug > Components: Futon >Reporter: Dale Harvey >Priority: Minor > Attachments: accept-json.patch > > > If you create / delete a database you are not allowed to, futon will make an > extra request and show the code to the index page in a dialog as the request > is forwarded to a login page, this is because jquery.couch.js doesnt specify > the accept headers so couchdb assumed the request is being made from a using > in the browser and not a http client -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1156) Futon shows apache license when performing unauthorised operations
[ https://issues.apache.org/jira/browse/COUCHDB-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-1156: - Attachment: accept-json.patch > Futon shows apache license when performing unauthorised operations > -- > > Key: COUCHDB-1156 > URL: https://issues.apache.org/jira/browse/COUCHDB-1156 > Project: CouchDB > Issue Type: Bug > Components: Futon >Reporter: Dale Harvey >Priority: Minor > Attachments: accept-json.patch > > > If you create / delete a database you are not allowed to, futon will make an > extra request and show the code to the index page in a dialog as the request > is forwarded to a login page, this is because jquery.couch.js doesnt specify > the accept headers so couchdb assumed the request is being made from a using > in the browser and not a http client -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1156) Futon shows apache license when performing unauthorised operations
Futon shows apache license when performing unauthorised operations -- Key: COUCHDB-1156 URL: https://issues.apache.org/jira/browse/COUCHDB-1156 Project: CouchDB Issue Type: Bug Components: Futon Reporter: Dale Harvey Priority: Minor Attachments: accept-json.patch If you create / delete a database you are not allowed to, futon will make an extra request and show the code to the index page in a dialog as the request is forwarded to a login page, this is because jquery.couch.js doesnt specify the accept headers so couchdb assumed the request is being made from a using in the browser and not a http client -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
[ https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031452#comment-13031452 ] Chris Anderson commented on COUCHDB-1060: - The current implementation avoids a special server side API for creating documents in the _users database. Architecturally, I am fine with a special API for the user's database -- however it may make sense to keep it in the "shape" of the CouchDB API. So for instance creating a user would go through an _update function, which could compute the salt and hash, before storing in the _users db. The alternative would be to define a custom endpoint for POST requests to create documents in the user db, and then we'd have to bike-shed and document that API. However if someone wants to write all that code, I won't stop you. If energy is going to poured in here, the other thing we should consider is a "write-only" database mode, so that users can PUT and POST, but not GET. In this case the _update function would still be a good way to do the salt and hashing. Anyway, this is a distinct topic but related. > CouchDB should use a secure password hash method instead of the current one > --- > > Key: COUCHDB-1060 > URL: https://issues.apache.org/jira/browse/COUCHDB-1060 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 1.0.2 >Reporter: Nuutti Kotivuori >Assignee: Robert Newson >Priority: Minor > Fix For: 1.2 > > Attachments: pbkdf2.erl, pbkdf2.erl > > > CouchDB passwords are stored in a salted, hashed format of a 128-bit salt > combined with the password under SHA-1. This method thwarts rainbow table > attacks, but is utterly ineffective against any dictionary attacks as > computing SHA-1 is very fast indeed. > If passwords are to be stored in a non-plaintext equivalent format, the hash > function needs to be a "slow" hash function. Suitable candidates for this > could be bcrypt, scrypt and PBKDF2. Of the choices, only PBKDF2 is really > widely used, standardized and goverment approved. (Note: don't be fooled that > the PBKDF2 is a "key derivation" function - in this case, it is exactly the > same thing as a slow password hash.) > http://en.wikipedia.org/wiki/PBKDF2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-906) Please offer offline downloadable documentation
The couch wiki needs to be hosted on couchdb, ready for local replication :) On Tue, May 10, 2011 at 2:46 PM, Chris Wilson (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031369#comment-13031369 > ] > > Chris Wilson commented on COUCHDB-906: > -- > > Hi all, > > I just tried this again, and when I try to access > http://couchdb.couchdb.org/wiki I get a page that says simply: > > "Host not found" > > This appears to be a server-side error rather than a browser error message. > Perhaps the documentation wiki has got broken somehow? Could someone look > into it please? > > Cheers, Chris. > > > Please offer offline downloadable documentation > > --- > > > > Key: COUCHDB-906 > > URL: https://issues.apache.org/jira/browse/COUCHDB-906 > > Project: CouchDB > > Issue Type: Improvement > > Components: Documentation > > Reporter: Chris Wilson > > > > I mainly work on the train or in airports without Internet access, so I > > need offline documentation. > > I tried to wget -r the couchdb wiki but I hit some kind of flood protection. > > Apparently MoinMoin can sync between two instances if xmlrpc is enabled. It > > seems to be enabled but broken in the CouchDB wiki. > > Please could you put the wiki pages into hg or git and offer a read-only > > clone or a downloadable tarball of the html versions of the pages? > > Cheers, Chris. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira
Tips for getting past test suite errors
Hello-
I'm new to couchdb-dev and am trying to get to the point where I can
make useful contributions. Right now 8 of my tests are failing when I
run the test suite in futon (details below).
I'm running on an Ubuntu 10.04.2 Server virtualbox, and I've forked
and cloned apache/couchdb on github and am up to date with
git.apache.org/couchdb.git (so I think I have the latest trunk).
I've followed these instructions for running couchdb in dev mode:
http://wiki.apache.org/couchdb/Running%20CouchDB%20in%20Dev%20Mode
and I believe all my dependencies are in order (I was able to
bootstrap, configure, and build successfully). Are these errors
expected? If not, any pointers for how to get started tracking down
what might be wrong with my setup?
basics success 14232ms
all_docssuccess 6441ms
attachments error 5699ms
Run with debugger
Assertion failed: xhr.responseText == lorem
Exception raised: {"message":"actual is
null","fileName":"http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0","lineNumber":322,"stack":"TEqualsIgnoreCase(\"text/plain;charset=utf-8\",null)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:322\u000a(false)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:147\u000arun(0)@http://192.168.2.13:5984/_utils/script/couch_test_runner.js?0.11.0:91\u000a"}
attachments_multipart success 4498ms
attachment_namessuccess 1643ms
attachment_pathssuccess 3852ms
attachment_ranges success 3046ms
attachment_viewssuccess 2370ms
auth_cache success 16065ms
batch_save success 67251ms
bulk_docs success 4190ms
changes success 19200ms
compact success 11128ms
config success 4686ms
conflicts success 2191ms
content_negotiation success 1253ms
cookie_auth success 12960ms
copy_docsuccess 2367ms
delayed_commits success 25500ms
design_docs success 40423ms
design_options success 2835ms
design_pathssuccess 3316ms
erlang_viewssuccess 5132ms
etags_head failure 2012ms
Run with debugger
Assertion failed: xhr.status == 304
etags_views success 12380ms
form_submit success 558ms
httpsuccess 1980ms
invalid_docids success 1386ms
jsonp success 2227ms
large_docs success 1504ms
list_views failure 6230ms
Run with debugger
Assertion 'xhr.status == 200, "standard get should be 200"'
failed: standard get should be 200
Assertion failed: /head0123456789tail/.test(xhr.responseText)
lots_of_docssuccess 1329ms
method_override success 1730ms
multiple_rows success 2342ms
oauth success 15701ms
proxyauth success 5462ms
purge success 8323ms
reader_acl success 11426ms
recreate_docsuccess 10891ms
reduce success 38180ms
reduce_builtin failure 50824ms
Run with debugger
Assertion failed: db.info().doc_count == (i - 1) * 10 * 11 + (j + 1) * 11
reduce_falsesuccess 1184ms
reduce_false_temp success 1171ms
replication success 554998ms
replicator_db failure 137115ms
Run with debugger
Assertion failed: typeof repDoc2._replication_state === "undefined"
Assertion failed: typeof repDoc2._replication_state_time === "undefined"
rev_stemmingfailure 10205ms
Run with debugger
Assertion failed: db.open("bar", {revs:
true})._revisions.ids.length == newLimit + 1
Assertion failed: db.open("bar", {revs:
true})._revisions.ids.length == newLimit + 1
rewrite success 7711ms
security_validation success 26567ms
show_documents success 9692ms
stats failure 43987ms
Run with debugger
Assertion 'triggered, "We managed to force a all_dbs_active
error."' failed: We managed to force a all_dbs_active error.
update_documentssuccess 5215ms
users_dbsuccess 4339ms
utf8success 3098ms
uuids success 2186ms
view_collation success 13409ms
view_collation_raw success 7263ms
view_conflicts success 2533ms
view_compaction success 5684ms
view_errors success 7816ms
view_include_docs success 7203ms
view_multi_key_all_docs success 3578ms
view_multi_key_design success 5621ms
view_multi_key_temp success 1158ms
view_offsetssuccess 23291ms
view_pagination success 15272ms
view_sandboxing failure 3380ms
Run with debugger
Assertion 'Warning: installed SpiderMonkey version doesn't allow
sealing of arrays' failed: expected '2', got '3'
view_update_seq success 10399ms
view_xmlsuccess 1728ms
[jira] [Commented] (COUCHDB-906) Please offer offline downloadable documentation
[ https://issues.apache.org/jira/browse/COUCHDB-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031369#comment-13031369 ] Chris Wilson commented on COUCHDB-906: -- Hi all, I just tried this again, and when I try to access http://couchdb.couchdb.org/wiki I get a page that says simply: "Host not found" This appears to be a server-side error rather than a browser error message. Perhaps the documentation wiki has got broken somehow? Could someone look into it please? Cheers, Chris. > Please offer offline downloadable documentation > --- > > Key: COUCHDB-906 > URL: https://issues.apache.org/jira/browse/COUCHDB-906 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Chris Wilson > > I mainly work on the train or in airports without Internet access, so I need > offline documentation. > I tried to wget -r the couchdb wiki but I hit some kind of flood protection. > Apparently MoinMoin can sync between two instances if xmlrpc is enabled. It > seems to be enabled but broken in the CouchDB wiki. > Please could you put the wiki pages into hg or git and offer a read-only > clone or a downloadable tarball of the html versions of the pages? > Cheers, Chris. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1075) Circular require's in CommonJS modules
[ https://issues.apache.org/jira/browse/COUCHDB-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031289#comment-13031289 ] Paul Joseph Davis commented on COUCHDB-1075: @mikeal Sounds good, thanks for the check. I'll commit this tonight. > Circular require's in CommonJS modules > -- > > Key: COUCHDB-1075 > URL: https://issues.apache.org/jira/browse/COUCHDB-1075 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Caolan McMahon > Labels: javascript > Attachments: module_cache.diff > > > Having a CommonJS module A which requires B, when B also requires A causes > the stack to fill up with require calls. A prerequisite for this fix is the > caching of modules, even if it is only on a per-request basis. > Patch incoming. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1075) Circular require's in CommonJS modules
[ https://issues.apache.org/jira/browse/COUCHDB-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031287#comment-13031287 ] mikeal commented on COUCHDB-1075: - i just took a glance at it. looks good. but patches in this code tend to cause weird bugs we don't find until people actually use it, the face that there are tests added makes me feel good about it. i say merge it. > Circular require's in CommonJS modules > -- > > Key: COUCHDB-1075 > URL: https://issues.apache.org/jira/browse/COUCHDB-1075 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Caolan McMahon > Labels: javascript > Attachments: module_cache.diff > > > Having a CommonJS module A which requires B, when B also requires A causes > the stack to fill up with require calls. A prerequisite for this fix is the > caching of modules, even if it is only on a per-request basis. > Patch incoming. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1155) Etag send by list function does not depend on userCtx
Etag send by list function does not depend on userCtx
-
Key: COUCHDB-1155
URL: https://issues.apache.org/jira/browse/COUCHDB-1155
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0.2
Reporter: Johannes J. Schmidt
List functions should send a different Etag when requested by different users.
The following curl session shows identical Etags for different users. CouchDB
must not be in admin party mode.
PROTOCOL=http
DOMAIN="127.0.0.1:5984"
DB=testdb
# admin credentials for db creation
ADMIN=admin:secure
# this user must have an empty roles array
USER=user:secure
curl -XDELETE $PROTOCOL://$ADMIN@$DOMAIN/$DB
curl -XPUT $PROTOCOL://$ADMIN@$DOMAIN/$DB
curl -XPUT $PROTOCOL://$ADMIN@$DOMAIN/$DB/foo -d '{"count":1}'
curl -XPUT $PROTOCOL://$ADMIN@$DOMAIN/$DB/_design/foo -d '{ "views": { "bar": {
"map": "function(doc) { emit(doc._id, null); }" } }, "lists": { "bar":
"function(head, req) { return req.userCtx.name || \"anonymous\" }" }}'
curl -s $PROTOCOL://$DOMAIN/$DB/_design/foo/_list/bar/bar --head | grep Etag
curl -s $PROTOCOL://$USER@$DOMAIN/$DB/_design/foo/_list/bar/bar --head | grep
Etag
#=> Etag: "A1NKHA0935KMCSHFSK94EHZNL"
#=> Etag: "A1NKHA0935KMCSHFSK94EHZNL"
This issue is important for standalone CouchDB applications which use list
functions depending on the user context, eg. showing a login button or username.
regards
Johannes
PS: I tried to write a javascript test case but this issue can only be
reproduced if the server is not in admin party mode, which the test suite
requires. I am not so familar with those tests to temporarily change the admin
party.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Helping out with releases
On Tue, May 10, 2011 at 9:49 AM, Jan Lehnardt wrote: > Putting 140 on an infinite loop (while(true); do ./test/etap/run > test/etap/140-attachment-comp.t ; done) eventually gives me > http://www.friendpaste.com/2JCA8dvre9orA3UysYYTCe on both SSD Mac OS X 10.6 > and Ubuntu 10.04 on disk in a VMWare. > That's the error that I was getting. > I also got one instance of http://www.friendpaste.com/7EpB1eJGRoRFBvjXvmFG3V > on the Ubuntu. > Never seen this one which makes things more fun. > The first one comes up reliably after half a minute or so and repeats itself, > it may well be a socket ulimit or something. The second one I only ever saw > once so far. > > Cheers > Jan > -- > > >
Re: Helping out with releases
More info: the Mac is on R14B02 and Ubuntu is on R13B03. Cheers Jan -- On 10 May 2011, at 15:49, Jan Lehnardt wrote: > Putting 140 on an infinite loop (while(true); do ./test/etap/run > test/etap/140-attachment-comp.t ; done) eventually gives me > http://www.friendpaste.com/2JCA8dvre9orA3UysYYTCe on both SSD Mac OS X 10.6 > and Ubuntu 10.04 on disk in a VMWare. > > I also got one instance of http://www.friendpaste.com/7EpB1eJGRoRFBvjXvmFG3V > on the Ubuntu. > > The first one comes up reliably after half a minute or so and repeats itself, > it may well be a socket ulimit or something. The second one I only ever saw > once so far. > > Cheers > Jan > -- > >
Re: Helping out with releases
Putting 140 on an infinite loop (while(true); do ./test/etap/run test/etap/140-attachment-comp.t ; done) eventually gives me http://www.friendpaste.com/2JCA8dvre9orA3UysYYTCe on both SSD Mac OS X 10.6 and Ubuntu 10.04 on disk in a VMWare. I also got one instance of http://www.friendpaste.com/7EpB1eJGRoRFBvjXvmFG3V on the Ubuntu. The first one comes up reliably after half a minute or so and repeats itself, it may well be a socket ulimit or something. The second one I only ever saw once so far. Cheers Jan --
Re: Helping out with releases
On 10 May 2011, at 15:28, Paul Davis wrote: > On Tue, May 10, 2011 at 9:24 AM, Jan Lehnardt wrote: >> >> On 10 May 2011, at 15:21, Paul Davis wrote: >> >>> On Tue, May 10, 2011 at 8:29 AM, Dirkjan Ochtman wrote: On Tue, May 10, 2011 at 14:08, Paul Davis wrote: > Like Jan says, it'd be awesome to have more people familiar with the > release procedure. Although if you're interested in speeding up > releases the best place to start would be by learning some internals. > The issues that usually keep things from shipping is that a test is > randomly failing or there's a bug waiting to be fixed. Right, but that's not the case now, is it? So I would like to help out with all the non-internals and chasing after other committers to fix up the bugs, as that seems an area that's currently understaffed. Which doesn't mean that maybe I won't get into the internals at some point, but I think doing the other things could be valuable to, and the project needs more of it. Cheers, Dirkjan >>> >>> I haven't run through prepping the 1.1.x branch for a release, but >>> 1.0.3 is being held up because I've sen the 090 and 140 etap tests >>> fail and no one (me included) has felt like fixing them yet. >> >> This is the first time I hear of this (I'm a little behind on JIRA), >> is there a ticket for this? What system specs do you have where you >> see the errors? >> >> Cheers >> Jan >> -- >> >> >> > > New 13" MBA. I've seen the 090 and 140 etap tests both fail. New 13" > MBA. I can get 140 to reproduce by running it many times. Haven't yet > tried to reproduce 090 (but it was during a distcheck for anyone > trying). Is this on SSD or spinning disk? Cheers Jan --
Re: Helping out with releases
On Tue, May 10, 2011 at 9:24 AM, Jan Lehnardt wrote: > > On 10 May 2011, at 15:21, Paul Davis wrote: > >> On Tue, May 10, 2011 at 8:29 AM, Dirkjan Ochtman wrote: >>> On Tue, May 10, 2011 at 14:08, Paul Davis >>> wrote: Like Jan says, it'd be awesome to have more people familiar with the release procedure. Although if you're interested in speeding up releases the best place to start would be by learning some internals. The issues that usually keep things from shipping is that a test is randomly failing or there's a bug waiting to be fixed. >>> >>> Right, but that's not the case now, is it? So I would like to help out >>> with all the non-internals and chasing after other committers to fix >>> up the bugs, as that seems an area that's currently understaffed. >>> >>> Which doesn't mean that maybe I won't get into the internals at some >>> point, but I think doing the other things could be valuable to, and >>> the project needs more of it. >>> >>> Cheers, >>> >>> Dirkjan >>> >> >> I haven't run through prepping the 1.1.x branch for a release, but >> 1.0.3 is being held up because I've sen the 090 and 140 etap tests >> fail and no one (me included) has felt like fixing them yet. > > This is the first time I hear of this (I'm a little behind on JIRA), > is there a ticket for this? What system specs do you have where you > see the errors? > > Cheers > Jan > -- > > > New 13" MBA. I've seen the 090 and 140 etap tests both fail. New 13" MBA. I can get 140 to reproduce by running it many times. Haven't yet tried to reproduce 090 (but it was during a distcheck for anyone trying).
Re: Helping out with releases
Paul, I'll try to take a look at 090 and 140 tonight after work, I know I've seen 140 randomly failing. Bob On May 10, 2011, at 9:21 AM, Paul Davis wrote: > On Tue, May 10, 2011 at 8:29 AM, Dirkjan Ochtman wrote: >> On Tue, May 10, 2011 at 14:08, Paul Davis >> wrote: >>> Like Jan says, it'd be awesome to have more people familiar with the >>> release procedure. Although if you're interested in speeding up >>> releases the best place to start would be by learning some internals. >>> The issues that usually keep things from shipping is that a test is >>> randomly failing or there's a bug waiting to be fixed. >> >> Right, but that's not the case now, is it? So I would like to help out >> with all the non-internals and chasing after other committers to fix >> up the bugs, as that seems an area that's currently understaffed. >> >> Which doesn't mean that maybe I won't get into the internals at some >> point, but I think doing the other things could be valuable to, and >> the project needs more of it. >> >> Cheers, >> >> Dirkjan >> > > I haven't run through prepping the 1.1.x branch for a release, but > 1.0.3 is being held up because I've sen the 090 and 140 etap tests > fail and no one (me included) has felt like fixing them yet.
Re: Helping out with releases
On 10 May 2011, at 15:21, Paul Davis wrote: > On Tue, May 10, 2011 at 8:29 AM, Dirkjan Ochtman wrote: >> On Tue, May 10, 2011 at 14:08, Paul Davis >> wrote: >>> Like Jan says, it'd be awesome to have more people familiar with the >>> release procedure. Although if you're interested in speeding up >>> releases the best place to start would be by learning some internals. >>> The issues that usually keep things from shipping is that a test is >>> randomly failing or there's a bug waiting to be fixed. >> >> Right, but that's not the case now, is it? So I would like to help out >> with all the non-internals and chasing after other committers to fix >> up the bugs, as that seems an area that's currently understaffed. >> >> Which doesn't mean that maybe I won't get into the internals at some >> point, but I think doing the other things could be valuable to, and >> the project needs more of it. >> >> Cheers, >> >> Dirkjan >> > > I haven't run through prepping the 1.1.x branch for a release, but > 1.0.3 is being held up because I've sen the 090 and 140 etap tests > fail and no one (me included) has felt like fixing them yet. This is the first time I hear of this (I'm a little behind on JIRA), is there a ticket for this? What system specs do you have where you see the errors? Cheers Jan --
Re: Helping out with releases
On Tue, May 10, 2011 at 8:29 AM, Dirkjan Ochtman wrote: > On Tue, May 10, 2011 at 14:08, Paul Davis wrote: >> Like Jan says, it'd be awesome to have more people familiar with the >> release procedure. Although if you're interested in speeding up >> releases the best place to start would be by learning some internals. >> The issues that usually keep things from shipping is that a test is >> randomly failing or there's a bug waiting to be fixed. > > Right, but that's not the case now, is it? So I would like to help out > with all the non-internals and chasing after other committers to fix > up the bugs, as that seems an area that's currently understaffed. > > Which doesn't mean that maybe I won't get into the internals at some > point, but I think doing the other things could be valuable to, and > the project needs more of it. > > Cheers, > > Dirkjan > Also, that's not meant to discourage from getting involved with RM. I think you're quite right that we need more people focusing on those aspects. I was just responding about the desire to have quicker releases.
Re: Helping out with releases
On Tue, May 10, 2011 at 8:29 AM, Dirkjan Ochtman wrote: > On Tue, May 10, 2011 at 14:08, Paul Davis wrote: >> Like Jan says, it'd be awesome to have more people familiar with the >> release procedure. Although if you're interested in speeding up >> releases the best place to start would be by learning some internals. >> The issues that usually keep things from shipping is that a test is >> randomly failing or there's a bug waiting to be fixed. > > Right, but that's not the case now, is it? So I would like to help out > with all the non-internals and chasing after other committers to fix > up the bugs, as that seems an area that's currently understaffed. > > Which doesn't mean that maybe I won't get into the internals at some > point, but I think doing the other things could be valuable to, and > the project needs more of it. > > Cheers, > > Dirkjan > I haven't run through prepping the 1.1.x branch for a release, but 1.0.3 is being held up because I've sen the 090 and 140 etap tests fail and no one (me included) has felt like fixing them yet.
Re: Helping out with releases
On Tue, May 10, 2011 at 14:08, Paul Davis wrote: > Like Jan says, it'd be awesome to have more people familiar with the > release procedure. Although if you're interested in speeding up > releases the best place to start would be by learning some internals. > The issues that usually keep things from shipping is that a test is > randomly failing or there's a bug waiting to be fixed. Right, but that's not the case now, is it? So I would like to help out with all the non-internals and chasing after other committers to fix up the bugs, as that seems an area that's currently understaffed. Which doesn't mean that maybe I won't get into the internals at some point, but I think doing the other things could be valuable to, and the project needs more of it. Cheers, Dirkjan
Re: Helping out with releases
Like Jan says, it'd be awesome to have more people familiar with the release procedure. Although if you're interested in speeding up releases the best place to start would be by learning some internals. The issues that usually keep things from shipping is that a test is randomly failing or there's a bug waiting to be fixed. On Tue, May 10, 2011 at 3:34 AM, Jan Lehnardt wrote: > Dirkjan, > > thanks for your offer, I think it is a great idea to add more helping > hands to the release process. > > The first stop for making a release is > http://wiki.apache.org/couchdb/Release_procedure > > In general, you should be able to build and test CouchDB from source > and be comfortable with the troubleshooting of issues, but I know > you are :) > > Cheers > Jan > -- > > > On 10 May 2011, at 09:25, Dirkjan Ochtman wrote: > >> Hi there, >> >> Since I note that the release process for 1.1 seems to have been >> stalled again, I wonder if there was stuff I could do. I'd be happy to >> join the RM team to help Apache CouchDB provide more timely releases >> so that companies like mine can benefit sooner from the latest fruits >> of the committers. >> >> Please let me know how I would go about learning all the stuff I need >> to know (and hopefully at some point keys to the required infra). >> >> Cheers, >> >> Dirkjan > >
[jira] [Commented] (COUCHDB-1045) Replication reports "missing" for docs which exist and are accesible
[
https://issues.apache.org/jira/browse/COUCHDB-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031117#comment-13031117
]
James Howe commented on COUCHDB-1045:
-
COUCHDB-1154 - Same symptoms of an underlying cause?
> Replication reports "missing" for docs which exist and are accesible
>
>
> Key: COUCHDB-1045
> URL: https://issues.apache.org/jira/browse/COUCHDB-1045
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.0.2
>Reporter: Rachel Willmer
>
> In one namespace we have, which has been migrated from 0.11.2 (and possibly
> from 0.9 before that), we have errors like these showing up in the log file
> when continuous replication is started.
> {noformat}
> [Thu, 27 Jan 2011 11:56:02 GMT] [error] [<0.467.0>] Replicator: error
> accessing doc uid_103172924375609852 at
> http://kvn1.back.incubator.telhc.local:15984/spaces/, reason:
> {"missing":"30-08f26139287d260e33299aa8caa65ea8"}
> [Thu, 27 Jan 2011 11:56:02 GMT] [error] [<0.466.0>] Replicator: error
> accessing doc uid_104478515691512449 at
> http://kvn1.back.incubator.telhc.local:15984/spaces/, reason:
> {"missing":"1-3c494a705f5eb472ba7b12a32be8555c"}
> [Thu, 27 Jan 2011 11:56:02 GMT] [error] [<0.465.0>] Replicator: error
> accessing doc uid_6042240 at
> http://kvn1.back.incubator.telhc.local:15984/spaces/, reason:
> {"missing":"12-47695f5504aff0c0049cf34befb60bcc"}
> {noformat}
> But, if you ask directly for those docs, they exist and are returned.
> In all cases I've tried, the _rev given as "missing" was the current one.
> They are returned both with and without the _rev option in the URL
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1154) Revisions returned by GET, but not include_docs
Revisions returned by GET, but not include_docs
---
Key: COUCHDB-1154
URL: https://issues.apache.org/jira/browse/COUCHDB-1154
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.0.2
Reporter: James Howe
We have a cluster of many couches replicating between each other, and are using
a view to find conflicts for resolution. However, running the view with
include_docs returns doc: null for some id/rev pairs. These revisions can be
retrieved using a simple GET, and appear as expected in the open_revs list.
map: function(doc) {
if (doc._conflicts) {
emit(doc._id, {_id: doc._id, _rev: doc._rev});
doc._conflicts.forEach(function(rev) {
emit(doc._id, {_id: doc._id, _rev: rev});
});
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1153) Database and view index compaction daemon
Database and view index compaction daemon - Key: COUCHDB-1153 URL: https://issues.apache.org/jira/browse/COUCHDB-1153 Project: CouchDB Issue Type: New Feature Environment: trunk Reporter: Filipe Manana Priority: Minor I've recently written an Erlang process to automatically compact databases and they're views based on some configurable parameters. These parameters can be global or per database and are: minimum database fragmentation, minimum view fragmentation, allowed period and "abortion" (whether an ongoing compaction should be stopped if it doesn't finish within the allowed period). These fragmentation values are based on the recently added "data_size" parameter to the database and view group information URIs (COUCHDB-1132). I've documented the .ini configuration here: https://github.com/fdmanana/couchdb/compare/compaction_daemon#diff-0 The full patch is mostly a new module but also does some minimal changes and a small refactoring to the view compaction code, not changing the current behaviour. Patch is at: https://github.com/fdmanana/couchdb/compare/compaction_daemon By default the daemon is idle, without any configuration enabled. I'm open to suggestions on additional parameters and a better configuration system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Helping out with releases
Dirkjan, thanks for your offer, I think it is a great idea to add more helping hands to the release process. The first stop for making a release is http://wiki.apache.org/couchdb/Release_procedure In general, you should be able to build and test CouchDB from source and be comfortable with the troubleshooting of issues, but I know you are :) Cheers Jan -- On 10 May 2011, at 09:25, Dirkjan Ochtman wrote: > Hi there, > > Since I note that the release process for 1.1 seems to have been > stalled again, I wonder if there was stuff I could do. I'd be happy to > join the RM team to help Apache CouchDB provide more timely releases > so that companies like mine can benefit sooner from the latest fruits > of the committers. > > Please let me know how I would go about learning all the stuff I need > to know (and hopefully at some point keys to the required infra). > > Cheers, > > Dirkjan
Helping out with releases
Hi there, Since I note that the release process for 1.1 seems to have been stalled again, I wonder if there was stuff I could do. I'd be happy to join the RM team to help Apache CouchDB provide more timely releases so that companies like mine can benefit sooner from the latest fruits of the committers. Please let me know how I would go about learning all the stuff I need to know (and hopefully at some point keys to the required infra). Cheers, Dirkjan
