[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-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: 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-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-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 #Port0.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 #Port0.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
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-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-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-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-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
