[jira] [Resolved] (COUCHDB-1413) Reduce queries with ?inclusive_end=false and endkey/endkey_docid or startkey/startkey_docid (if ?descending=true) produce incorrect reductions
[ https://issues.apache.org/jira/browse/COUCHDB-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1413. Resolution: Fixed Fix Version/s: 1.2 Applied to master and 1.2.x > Reduce queries with ?inclusive_end=false and endkey/endkey_docid or > startkey/startkey_docid (if ?descending=true) produce incorrect reductions > -- > > Key: COUCHDB-1413 > URL: https://issues.apache.org/jira/browse/COUCHDB-1413 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Filipe Manana >Assignee: Filipe Manana > Fix For: 1.2, 1.2.1 > > Attachments: 0001-Fix-fold-reduce-with-non-inclusive-end-key.patch, > 0001-Fix-fold-reduce-with-non-inclusive-end-key.patch, COUCHDB-1413.sh > > > COUCHDB-1047 attempted to fix endkey being ignored for reduce queries. It > works but it's busted when endkey_docid is also present, as it produces wrong > results. Using end_key_gt as an endkey in the btree fold reduce operation is > not enough to guarantee correct results for all cases. > The following script reproduces the issue and the following patch fixes it. -- 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] [Resolved] (COUCHDB-1394) Compaction doesn't allow to change database compression for version 6 databases
[ https://issues.apache.org/jira/browse/COUCHDB-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1394. Resolution: Fixed Fix and test applied to master and 1.2.x > Compaction doesn't allow to change database compression for version 6 > databases > --- > > Key: COUCHDB-1394 > URL: https://issues.apache.org/jira/browse/COUCHDB-1394 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Filipe Manana > Fix For: 1.2 > > Attachments: COUCHDB-1394.patch, COUCHDB-1394.patch > > > Issue described in the development mailing list thread: > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201201.mbox/%3CCAOZtSq1gXSk9Ait_zp3NuRbFpBPGfMwP7pdDzzEt-oDMr00eyQ%40mail.gmail.com%3E > Patch attached -- 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] [Resolved] (COUCHDB-1384) File descriptor leak if view compaction is cancelled
[ https://issues.apache.org/jira/browse/COUCHDB-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1384. Resolution: Fixed Applied to 1.2.x > File descriptor leak if view compaction is cancelled > > > Key: COUCHDB-1384 > URL: https://issues.apache.org/jira/browse/COUCHDB-1384 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Filipe Manana >Priority: Critical > Fix For: 1.2 > > Attachments: > 0001-Close-view-compaction-file-when-compaction-is-cancel.patch > > > If a view compaction is canceled, the compact file's fd remains open as long > as the view group is alive. > This is because the couch_file the compactor uses is spawn_linked by the view > group and not linked to the compactor process, therefore when the compactor > is shutdown the corresponding couch_file is not shutdown. The view group > doesn't keep track of the compact file's couch_file, so it can't explicitly > shutdown it either. > This affects only the 1.2.x branch and is addressed by simply linking the > file process to the compactor process. Patch attached. -- 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] [Resolved] (COUCHDB-1382) Use term_to_binary with minor_version=1 to reduce disk size of data and indexes
[ https://issues.apache.org/jira/browse/COUCHDB-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1382. Resolution: Fixed Fix Version/s: 1.2 This was already done in COUCHDB-1120, which will be included in the 1.2.0 release. > Use term_to_binary with minor_version=1 to reduce disk size of data and > indexes > --- > > Key: COUCHDB-1382 > URL: https://issues.apache.org/jira/browse/COUCHDB-1382 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 1.1.1 > Environment: doesn't matter >Reporter: Alexey Loshkarev >Priority: Trivial > Fix For: 1.2 > > > Now, couchdb store data using term_to_binary/1 (with no options). > According manual, term_to_binary/2 has option minor_version, which value 1 > changes storage format for floats. > Default behaviour, float consume 33 bytes of disk space. > With minor_version=1, float consume only 9 bytes of disk space. > minor_version=1 is supported since Erlance 11B-4, but minimum couchdb > supported erlang version is still 13, so no problem to implement this. > Also, term_to_binary/2 has "compressed" option, it may also reduce disk > space, but will use more cpu for that. -- 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] [Resolved] (COUCHDB-1309) File descriptor leaks on design document update and view cleanup
[ https://issues.apache.org/jira/browse/COUCHDB-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1309. Resolution: Fixed Fix applied to 1.2.x and master. > File descriptor leaks on design document update and view cleanup > > > Key: COUCHDB-1309 > URL: https://issues.apache.org/jira/browse/COUCHDB-1309 > Project: CouchDB > Issue Type: Bug >Reporter: Filipe Manana >Assignee: Filipe Manana > Fix For: 1.2 > > Attachments: > 0001-Fix-ets-lookup-case_clause-error-after-ddoc-is-updat.patch, > 12x-0001-Add-ddoc_updated-event.patch, > 12x-0002-Shutdown-view-group-on-ddoc-update.patch, couchdb-1309_12x.patch, > couchdb-1309_trunk.patch, master-0001-Add-ddoc_updated-event.patch, > master-0002-Shutdown-view-group-on-ddoc-update.patch, > master-0002-Shutdown-view-group-on-ddoc-update.patch > > > If we add a design document with views defined in it, open the corresponding > view group (by querying one of its views for e.g.), then update the design > document in such a way that the view signature changes (changing a view's map > function code for e.g), the old view group remains open forever (unless a > server restart happens) and keeps it's view file reference counter active > forever. > If a view cleanup request comes, the old view file is not deleted since the > reference counter is not dropped by the old view group, keeping the file > descriptor in use forever. > This leakage is different from what is reported in COUCHDB-1129 but it's > somehow related. > The attached patch, simply shutdowns a view group when the design document is > updated and the new view signature changes, releasing the old view file > descriptor (as soon as no more clients are using the old view). -- 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] [Resolved] (COUCHDB-188) _bulk_docs fails when deleting and adding a doc with the same id
[
https://issues.apache.org/jira/browse/COUCHDB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-188.
---
Resolution: Fixed
Fix applied to master (6d1d23b7d0eba4de3c4097907adc37b09191196e).
> _bulk_docs fails when deleting and adding a doc with the same id
>
>
> Key: COUCHDB-188
> URL: https://issues.apache.org/jira/browse/COUCHDB-188
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
> Environment: CouchDB revision 730414.
>Reporter: Matt Goodall
>Assignee: Filipe Manana
>Priority: Blocker
> Fix For: 1.3
>
> Attachments:
> 0001-Allow-doc-delete-and-creation-in-the-same-bulk-updat.patch
>
>
> CouchDB returns a "412 Precondition Failed" when the list of changes sent to
> _bulk_docs deletes a document and later creates a document with the same id
> as the deleted document:
> {"docs": [
> {"_id": "docid", "_rev": "", "_deleted": true},
> {"_id": "docid"}
> ]}
> Once fixed, the response JSON document will return the same docid twice in
> the list but it's presumably ordered consistently with the request data so
> any client should be able to understand the response.
> Demonstrating the problem using curl is easy enough:
> $ curl -X PUT http://localhost:5984/test
> {"ok":true}
> $ curl -X PUT -d "{}" http://localhost:5984/test/docid
> {"ok":true,"id":"docid","rev":"4140747751"}
> $ curl -X POST -d '{"docs": [{"_id": "docid", "_rev": "4140747751",
> "_deleted": true}, {"_id": "docid"}]}' http://localhost:5984/test/_bulk_docs
> {"error":"conflict","reason":"Document update conflict."}
> Note: this is likely related to COUCHDB-172.
--
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] [Resolved] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1365. Resolution: Fixed Assignee: Filipe Manana Fix applied to master, 1.2.x and 1.1.x branches. > Fix merging of document with attachment stubs > - > > Key: COUCHDB-1365 > URL: https://issues.apache.org/jira/browse/COUCHDB-1365 > Project: CouchDB > Issue Type: Bug > Components: Database Core, Replication >Reporter: Filipe Manana >Assignee: Filipe Manana >Priority: Blocker > Fix For: 1.2, 1.1.2 > > Attachments: > 0001-Fix-merging-of-documents-with-attachment-stubs.patch, > 0001-Fix-merging-of-documents-with-attachment-stubs.patch, > reproduce-CBMA-22.sh > > > This issue was found by Marty Schoch and is reproducible the following > attached script. > The commit message in the patch explains the issue: > "During replicated updates, merging of documents with > attachment stubs will fail if, after merging the received > document's revision tree with the current on disk revision > tree, produces a revision tree which doesn't contain the revision > that immediately precedes the received document's revision. > This happens when the received document doesn't contain in its > revision history any of the revisions in the revision tree > of the currently on disk document. This is possible when the > document had a number of updates higher than the value of revs > limit defined for the source database." -- 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] [Resolved] (COUCHDB-1357) Authentication failure after updating password in user document
[ https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1357. Resolution: Fixed Fix Version/s: 1.2 Fix applied to master and 1.2.x > Authentication failure after updating password in user document > --- > > Key: COUCHDB-1357 > URL: https://issues.apache.org/jira/browse/COUCHDB-1357 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Filipe Manana > Fix For: 1.2 > > Attachments: 0001-Clear-credentials-cache-if-_users-db-crashes.patch, > 0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch > > > From the report at the users mailing list: > http://s.apache.org/9OG > Seems like after updating the password in a user doc, the user is not able to > login with the new password unless Couch is restarted. Sounds like a caching > issue. > The only case of getting the cache consistent with the _users database > content is if the _users database processes crash and after the crash user > documents are updated. The cache daemon is ignoring the database crash. > The following patch updates the daemon to monitor the _users database and > crash (letting the supervisor restart it) if the database process crashes. > Etap test included. > This might be related to COUCHDB-1212. -- 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] [Resolved] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1320. Resolution: Fixed Fix Version/s: 1.2 Assignee: Filipe Manana (was: Benoit Chesneau) Fix applied to master and 1.2.x > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham >Assignee: Filipe Manana > Fix For: 1.2 > > Attachments: Fix-OAuth-that-broke-with-vhost.patch, > fdmanana-0001-Fix-OAuth-authentication-with-VHosts-URL-rewriting.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- 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] [Resolved] (COUCHDB-1349) _replicator docs should include the additional info from _active_tasks
[
https://issues.apache.org/jira/browse/COUCHDB-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-1349.
Resolution: Fixed
Fix Version/s: 1.2
Applied to master and 1.2.x
> _replicator docs should include the additional info from _active_tasks
> --
>
> Key: COUCHDB-1349
> URL: https://issues.apache.org/jira/browse/COUCHDB-1349
> Project: CouchDB
> Issue Type: Improvement
> Components: Replication
>Reporter: Rogutės Sparnuotos
>Assignee: Filipe Manana
>Priority: Minor
> Fix For: 1.2
>
>
> There are some nice replication stats at /_active_tasks. I think that these
> should be exposed in the corresponding /_replicator documents (well, at least
> the first 3):
> {
> "doc_write_failures": 0,
> "docs_read": 0,
> "docs_written": 0,
> "updated_on": 1322521694,
> "started_on": 1322521569
> }
> This would make it easier to map a replication doc to its status.
> This would benefit Futon, which currently seems to have only a limited
> interface to /_active_tasks.
> This would bring _replicator closer to the old _replicate API, which returns
> the stats after one-time replication:
> {
> "ok": true,
> "no_changes": true,
> "session_id": "6647e26bc340b706bcf8f3c1ca709846",
> "source_last_seq": 95,
> "replication_id_version": 2,
> "history": [
> {
> "session_id": "6647e26bc340b706bcf8f3c1ca709846",
> "start_time": "Mon, 28 Nov 2011 23:44:28 GMT",
> "end_time": "Mon, 28 Nov 2011 23:44:33 GMT",
> "start_last_seq": 0,
> "end_last_seq": 95,
> "recorded_seq": 95,
> "missing_checked": 24,
> "missing_found": 24,
> "docs_read": 24,
> "docs_written": 24,
> "doc_write_failures": 0
> }
> ]
> }
--
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] [Resolved] (COUCHDB-1353) Adding security to the replication database leads to crashes
[
https://issues.apache.org/jira/browse/COUCHDB-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-1353.
Resolution: Fixed
Fix Version/s: 1.2
Thanks Martin.
This was caused by a recent changes on master and 1.2.x, it doesn't affect any
release.
Fix applied to those 2 branches.
> Adding security to the replication database leads to crashes
>
>
> Key: COUCHDB-1353
> URL: https://issues.apache.org/jira/browse/COUCHDB-1353
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.2
> Environment: Ubuntu
>Reporter: Martin Higham
> Fix For: 1.2
>
>
> If I set Admin and reader security on the replication database the replicator
> will crash when adding new records to the database with a "not authorised
> error". It will continue to crash while trying to restart replication and
> even after a restart
> 1. Create several databases and replication rules - everything works fine
> 2. Add reader security to the replication database
> 3. Insert new document into the replication database. Replication will record
> the error and stop all replication
> [Fri, 02 Dec 2011 10:45:36 GMT] [debug] [<0.216.0>] OS Process #Port<0.2851>
> Input :: ["ddoc","_design/_replicator",["valida
> te_doc_update"],[{"_id":"8d158931ac19d99f96f2aad68104aa09","target":"testrep","continuous":true,"source":"http://admin:a@
> 127.0.0.1:5984/dbz_molly","_revisions":{"start":0,"ids":[]}},null,{"db":"ndz_replicator","name":"admin","roles":["_admin"]},{
> "admins":{"names":[],"roles":["_admin","_replicator"]},"members":{"names":[],"roles":["_admin","_replicator"]}}]]
> [Fri, 02 Dec 2011 10:45:36 GMT] [debug] [<0.216.0>] OS Process #Port<0.2851>
> Output :: 1
> [Fri, 02 Dec 2011 10:45:36 GMT] [info] [<0.12560.0>] 109.150.210.170 - - PUT
> /ndz_replicator/8d158931ac19d99f96f2aad68104aa09
> 201
> [Fri, 02 Dec 2011 10:45:36 GMT] [debug] [<0.117.0>] Not a reader: UserCtx
> {user_ctx,null,[],undefined} vs Names [] Roles [<<"
> _admin">>,
>
> <<"_admin">>,
>
> <<"_replicator">>]
> [Fri, 02 Dec 2011 10:45:36 GMT] [error] [<0.110.0>] Replication manager
> received unexpected message {'EXIT',
>
> <0.117.0>,
>
> {{nocatch,
>
> {unauthorized,
>
> <<"You are not authorized to access this db.">>}},
>
> [{couch_db,
> open,
> 2},
>
> {couch_changes,
>
> keep_sending_changes,
> 9},
>
> {couch_changes,
>
> '-handle_changes/3-fun-1-',
> 5},
>
> {couch_replication_manager,
>
> '-changes_feed_loop/0-fun-1-',
> 2}]}}
> [Fri, 02 Dec 2011 10:45:36 GMT] [error] [emulator] Error in process <0.117.0>
> with exit value: {{nocatch,{unauthorized,<<41 b
> ytes>>}},[{couch_db,open,2},{couch_changes,keep_sending_changes,9},{couch_changes,'-handle_changes/3-fun-1-',5},{couch_replic
> ation_manager,'-changes_feed_loop/0-fun-1-',2}]}
> [Fri, 02 Dec 2011 10:45:36 GMT] [info] [<0.110.0>] Stopping all ongoing
> replications because the replicator database was deleted or changed
> I am testing against a trunk build of CouchDB but think I have seen similar
> behaviour on 1.1.x but hadn't pinned down the cause
--
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] [Resolved] (COUCHDB-1340) Replication: Invalid JSON reported
[
https://issues.apache.org/jira/browse/COUCHDB-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-1340.
Resolution: Fixed
Reduced the limit to 7000 on all active branches and applied the percent
encoding of query string values on master and 1.2.x only.
> Replication: Invalid JSON reported
> --
>
> Key: COUCHDB-1340
> URL: https://issues.apache.org/jira/browse/COUCHDB-1340
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1.1
> Environment: CentOS 5.6 x86_64, Couchdb 1.1.1 (Patched for
> COUCHDB-1333), spidermonkey 1.8.5, curl 7.21, erlang 14b03
>Reporter: Alex Markham
> Labels: invalid, json
> Fix For: 1.2, 1.1.2
>
> Attachments: 9c94ed0e23508f4ec3d18f8949c06a5b replicaton from
> wireshark cut.txt, old_rep_qs_encoding.patch, replication error
> wireshark.txt, source couch error.log, target couch error.log
>
>
> It seems our replication has stopped, reporting an error
> [emulator] Error in process <0.21599.306> {{nocatch,{invalid_json,<<0
> bytes>>}},[{couch_util,json_decode,1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,open_doc_revs,3},{couch_rep_reader,'-spawn_document_request/4-fun-0-'...
>
> It was all working until we upgraded some other couches in our replication
> "web" from couch 1.0.3 to couch 1.1.1. We then set of database and view
> compactions, and sometime overnight some of the replication links stopped.
> I have curled the command myself, both as a multipart message and a single
> json response (with header "Accept:application/json" ) and it can be parsed
> correctly by Python simplejson - I have attached it here aswell - called
> "troublecurl-redacted.txt" - though it is 18.8mb. The request takes about 6
> seconds.
> I don't quite understand why it is reported as invalid JSON? Other reports
> similar to this that I googled mentioned blank document ids, but I can't see
> any of these.
--
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] [Resolved] (COUCHDB-1340) Replication: Invalid JSON reported
[
https://issues.apache.org/jira/browse/COUCHDB-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-1340.
Resolution: Fixed
Fix Version/s: 1.1.2
1.2
Fix applied to master, 1.2.x and 1.1.x
> Replication: Invalid JSON reported
> --
>
> Key: COUCHDB-1340
> URL: https://issues.apache.org/jira/browse/COUCHDB-1340
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1.1
> Environment: CentOS 5.6 x86_64, Couchdb 1.1.1 (Patched for
> COUCHDB-1333), spidermonkey 1.8.5, curl 7.21, erlang 14b03
>Reporter: Alex Markham
> Labels: invalid, json
> Fix For: 1.2, 1.1.2
>
> Attachments: 9c94ed0e23508f4ec3d18f8949c06a5b replicaton from
> wireshark cut.txt, replication error wireshark.txt, source couch error.log,
> target couch error.log
>
>
> It seems our replication has stopped, reporting an error
> [emulator] Error in process <0.21599.306> {{nocatch,{invalid_json,<<0
> bytes>>}},[{couch_util,json_decode,1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,open_doc_revs,3},{couch_rep_reader,'-spawn_document_request/4-fun-0-'...
>
> It was all working until we upgraded some other couches in our replication
> "web" from couch 1.0.3 to couch 1.1.1. We then set of database and view
> compactions, and sometime overnight some of the replication links stopped.
> I have curled the command myself, both as a multipart message and a single
> json response (with header "Accept:application/json" ) and it can be parsed
> correctly by Python simplejson - I have attached it here aswell - called
> "troublecurl-redacted.txt" - though it is 18.8mb. The request takes about 6
> seconds.
> I don't quite understand why it is reported as invalid JSON? Other reports
> similar to this that I googled mentioned blank document ids, but I can't see
> any of these.
--
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] [Resolved] (COUCHDB-1334) Indexer speedup (for non-native view servers)
[
https://issues.apache.org/jira/browse/COUCHDB-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-1334.
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.3
Latest patch applied against master.
> Indexer speedup (for non-native view servers)
> -
>
> Key: COUCHDB-1334
> URL: https://issues.apache.org/jira/browse/COUCHDB-1334
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core, JavaScript View Server, View Server
> Support
>Reporter: Filipe Manana
>Assignee: Filipe Manana
> Fix For: 1.3
>
> Attachments: 0001-More-efficient-view-updater-writes.patch,
> 0002-More-efficient-communication-with-the-view-server.patch,
> master-0002-More-efficient-communication-with-the-view-server.patch,
> master-2-0002-More-efficient-communication-with-the-view-server.patch,
> master-3-0002-More-efficient-communication-with-the-view-server.patch,
> master-4-0002-More-efficient-communication-with-the-view-server.patch
>
>
> The following 2 patches significantly improve view index generation/update
> time and reduce CPU consumption.
> The first patch makes the view updater's batching more efficient, by ensuring
> each btree bulk insertion adds/removes a minimum of N (=100) key/value
> pairts. This also makes the index file size grow not so fast with old data
> (old btree nodes basically). This behaviour is already done in master/trunk
> in the new indexer (by Paul Davis).
> The second patch maximizes the throughput with an external view server (such
> as couchjs). Basically it makes the pipe (erlang port) communication between
> the Erlang VM (couch_os_process basically) and the view server more efficient
> since the 2 sides spend less time block on reading from the pipe.
> Here follow some benchmarks.
> test database at http://fdmanana.iriscouch.com/test_db (1 million documents)
> branch 1.2.x
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real 2m45.097s
> user 0m0.006s
> sys 0m0.007s
> view file size: 333Mb
> CPU usage:
> $ sar 1 60
> 22:27:20 %usr %nice %sys %idle
> 22:27:21 38 0 12 50
> ()
> 22:28:21 39 0 13 49
> Average: 39 0 13 47
> branch 1.2.x + batch patch (first patch)
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real 2m12.736s
> user 0m0.006s
> sys 0m0.005s
> view file size 72Mb
> branch 1.2.x + batch patch + os_process patch
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real 1m9.330s
> user 0m0.006s
> sys 0m0.004s
> view file size: 72Mb
> CPU usage:
> $ sar 1 60
> 22:22:55 %usr %nice %sys %idle
> 22:23:53 22 0 6 72
> ()
> 22:23:55 22 0 6 72
> Average: 22 0 7 70
> master/trunk
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real 1m57.296s
> user 0m0.006s
> sys 0m0.005s
> master/trunk + os_process patch
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real 0m53.768s
> user 0m0.006s
> sys 0m0.006s
--
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] [Resolved] (COUCHDB-1309) File descriptor leaks on design document update and view cleanup
[ https://issues.apache.org/jira/browse/COUCHDB-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1309. Resolution: Fixed Fix Version/s: 1.2 Applied to master and branch 1.2.x > File descriptor leaks on design document update and view cleanup > > > Key: COUCHDB-1309 > URL: https://issues.apache.org/jira/browse/COUCHDB-1309 > Project: CouchDB > Issue Type: Bug >Reporter: Filipe Manana >Assignee: Filipe Manana > Fix For: 1.2 > > Attachments: 12x-0001-Add-ddoc_updated-event.patch, > 12x-0002-Shutdown-view-group-on-ddoc-update.patch, couchdb-1309_12x.patch, > couchdb-1309_trunk.patch, master-0001-Add-ddoc_updated-event.patch, > master-0002-Shutdown-view-group-on-ddoc-update.patch, > master-0002-Shutdown-view-group-on-ddoc-update.patch > > > If we add a design document with views defined in it, open the corresponding > view group (by querying one of its views for e.g.), then update the design > document in such a way that the view signature changes (changing a view's map > function code for e.g), the old view group remains open forever (unless a > server restart happens) and keeps it's view file reference counter active > forever. > If a view cleanup request comes, the old view file is not deleted since the > reference counter is not dropped by the old view group, keeping the file > descriptor in use forever. > This leakage is different from what is reported in COUCHDB-1129 but it's > somehow related. > The attached patch, simply shutdowns a view group when the design document is > updated and the new view signature changes, releasing the old view file > descriptor (as soon as no more clients are using the old view). -- 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] [Resolved] (COUCHDB-1336) coffeescript tests are not getting installed
[ https://issues.apache.org/jira/browse/COUCHDB-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1336. Resolution: Fixed Fix Version/s: 1.2 Applied to master and branch 1.2.x. Thanks Klaus. > coffeescript tests are not getting installed > > > Key: COUCHDB-1336 > URL: https://issues.apache.org/jira/browse/COUCHDB-1336 > Project: CouchDB > Issue Type: Test > Components: Test Suite >Reporter: Klaus Trainer >Priority: Trivial > Labels: javascript, test > Fix For: 1.2 > > Attachments: > 0001-Add-www-script-test-coffee.js-to-share-Makefile.am.patch > > > The file that contains the tests for coffeescript support > (`www/script/test/coffee.js`) is missing in `share/Makefile.am`. Therefore it > doesn't get installed and the tests can't be executed in Futon (there's a 404 > when the file is requested). -- 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] [Resolved] (COUCHDB-509) RFE: make futon show view execution timings
[ https://issues.apache.org/jira/browse/COUCHDB-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-509. --- Resolution: Fixed Fix Version/s: 1.3 Applied to master > RFE: make futon show view execution timings > --- > > Key: COUCHDB-509 > URL: https://issues.apache.org/jira/browse/COUCHDB-509 > Project: CouchDB > Issue Type: Improvement > Components: Futon >Reporter: Alexander Todorov > Fix For: 1.3 > > Attachments: jira-couchdb-509-patch-for-trunk.patch > > > Please add view execution/generation time in the Futon web interface. > Something like: > ... results ... > page generated in 1.234 ms -- 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] [Resolved] (COUCHDB-1333) views hangs, time-out occurs, error probably related to COUCHDB-1246
[
https://issues.apache.org/jira/browse/COUCHDB-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana resolved COUCHDB-1333.
Resolution: Fixed
Fix Version/s: 1.2
Fixed in master and branch 1.2.x
> views hangs, time-out occurs, error probably related to COUCHDB-1246
> -
>
> Key: COUCHDB-1333
> URL: https://issues.apache.org/jira/browse/COUCHDB-1333
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.1.1
> Environment: centos 5.5
>Reporter: Armen Arsakian
> Labels: javascript
> Fix For: 1.2
>
>
> My permanent views are stalled, get responses never arrive from couchdb utill
> a time-out error occurs.
> Once I managed to get the following error:
> timeout {gen_server,call,[couch_query_servers,{get_proc,<<"javascript">>}]}
> I found the following similar issue
> https://issues.apache.org/jira/browse/COUCHDB-1246
> but this was closed at 18/8/2011.
> I guess this is not fixed yet, I installed couchDB from source which I
> downloaded today, version: 1.1.1
> Is this issue still open.
> In my opensuse I have not any problem with views. version 1.1.0
> but in production machine a centos 5.5 i get the above error.
--
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] [Resolved] (COUCHDB-1325) verify_ssl_certificates in local.ini's [ssl] section doesn't work?
[ https://issues.apache.org/jira/browse/COUCHDB-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1325. Resolution: Fixed Fix Version/s: 1.2 Fix applied to master and branch 1.2.x > verify_ssl_certificates in local.ini's [ssl] section doesn't work? > -- > > Key: COUCHDB-1325 > URL: https://issues.apache.org/jira/browse/COUCHDB-1325 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Rogutės Sparnuotos >Priority: Minor > Fix For: 1.2 > > Attachments: couchdb-1325.patch, debug_run.log > > > The shipped local.ini has this: > [ssl] > verify_ssl_certificates = false > When I add a cert_file and a key_file, and enable https in [daemons], couchdb > refuses to start: > "Verify SSL certificate enabled but file containing PEM encoded CA > certificates is missing". > The funny thing is that CouchDB doesn't refuse to start when the > "verify_ssl_certificates" line is commented out. -- 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] [Resolved] (COUCHDB-1009) Make couch_stream buffer configurable
[ https://issues.apache.org/jira/browse/COUCHDB-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1009. Resolution: Fixed Applied to master. > Make couch_stream buffer configurable > - > > Key: COUCHDB-1009 > URL: https://issues.apache.org/jira/browse/COUCHDB-1009 > Project: CouchDB > Issue Type: Improvement > Components: Database Core > Environment: trunk >Reporter: Filipe Manana >Assignee: Filipe Manana >Priority: Trivial > Attachments: COUCHDB-1009-2.patch, COUCHDB-1009-rebased.patch, > COUCHDB-1009.patch > > > The couch_stream buffer is hardcoded to 4Kb. > This value should be configurable. Larger values can improve write and > specially read performance (if we write larger chunks to disk, we have higher > chances of reading more contiguous disk blocks afterwards). > I also think it's a good idea to change the default value from 4Kb to > something higher (64Kb for e.g.). > Patch attached -- 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] [Resolved] (COUCHDB-1129) file descriptors sometimes not closed after compaction
[ https://issues.apache.org/jira/browse/COUCHDB-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1129. Resolution: Fixed Fix Version/s: 1.1.1 Good to now. If it happens again, please reopen this ticket. Thanks for testing it > file descriptors sometimes not closed after compaction > -- > > Key: COUCHDB-1129 > URL: https://issues.apache.org/jira/browse/COUCHDB-1129 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.0.2 >Reporter: Randall Leeds > Fix For: 1.1.1, 1.2 > > > It seems there are still cases where file descriptors are not released upon > compaction finishing. > When I asked on IRC rnewson confirmed he'd seen the behavior also and the > last comment on 926 also suggests there are still times where this occurs. > Someone needs to take a careful eye to any race conditions we might have > between opening the file and subscribing to the compaction notification. -- 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
