[jira] [Created] (COUCHDB-1468) DB Compaction does not log detected / removed duplicates
DB Compaction does not log detected / removed duplicates Key: COUCHDB-1468 URL: https://issues.apache.org/jira/browse/COUCHDB-1468 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.2, 1.1.1, 1.0.3 Reporter: Stefan Kögl Priority: Minor According to Robert News on user@ [1] the db compaction does not log detected / removed duplicates. Even if one assumes that no new duplicates are created with recent versions, there might still be existing databases with duplicates. Detecting such would be made easier if db compaction would log any found occurances. [1] http://mail-archives.apache.org/mod_mbox/couchdb-user/201204.mbox/browser -- 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] [Created] (COUCHDB-1467) update wiki CSS in line with mailing list proposal
update wiki CSS in line with mailing list proposal -- Key: COUCHDB-1467 URL: https://issues.apache.org/jira/browse/COUCHDB-1467 Project: CouchDB Issue Type: Improvement Components: Documentation Environment: Apache Wiki Reporter: Dave Cottlehuber Priority: Trivial Per discussion in http://mail-archives.apache.org/mod_mbox/couchdb-dev/201202.mbox/%3cca+y+446meiyfe6zrqmkav6m7u3fynsfpvbbpchs3nyvzq0c...@mail.gmail.com%3E and front page http://samizdat.cc/couchdb/ logo http://samizdat.cc/moin_static188/modernized/img/couchdb-wiki-logo-small.png css http://samizdat.cc/moin_static188/modernized/css/screen.css How to: http://moinmo.in/HelpOnThemes & http://www.pantz.org/software/moinmoin/setup_moinmoin_wiki.html Couch config: https://svn.apache.org/repos/infra/infrastructure/apwiki/trunk/config/couchdb.py Data dir: minotaur:/www/wiki.apache.org/data/couchdb Current themes: /www/wiki.apache.org/share/moin/htdocs/ Looks like approach is to duplicate theme under couchdb data dir, add changes, recommit. -- 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] [Created] (COUCHDB-1466) Create persistent replications via Futon
Create persistent replications via Futon Key: COUCHDB-1466 URL: https://issues.apache.org/jira/browse/COUCHDB-1466 Project: CouchDB Issue Type: New Feature Components: Futon Affects Versions: 1.2 Reporter: James Howe Futon's replicator page should have the option of making the task persistent (i.e. it should add a document to _replictor rather than making the usual POST). Probably implemented as another checkbox next to "Continuous". -- 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] [Created] (COUCHDB-1465) _list should be able to send binary data to the client
_list should be able to send binary data to the client -- Key: COUCHDB-1465 URL: https://issues.apache.org/jira/browse/COUCHDB-1465 Project: CouchDB Issue Type: Improvement Reporter: Johannes J. Schmidt Priority: Minor You can send binary data with show and update functions. It would be great if one also could send binary data via list functions. There is an old thread about that from 2010: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201001.mbox/%3c20100118143956.ga7...@uk.tiscali.com%3E -- 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] [Created] (COUCHDB-1464) Unable to login to CouchDB
Unable to login to CouchDB -- Key: COUCHDB-1464 URL: https://issues.apache.org/jira/browse/COUCHDB-1464 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.3 Environment: Apache CouchDB 1.0.1 Ubuntu 10.04.2 LTS. Reporter: Petter Olofsson Hi, Login to server with ordinary user accounts stopped working. Logging in with admin's defined in local.ini still worked, but user account created as documents always responded with username/password incorrect. When the old users did not work, we started to create new users in Futon. Here are the requests from the logs when a user is created, and the failed login afterwards. [Thu, 12 Apr 2012 14:22:57 GMT] [info] [<0.1392.0>] - - 'PUT' /_users/org.couchdb.user%3Apetter 201 [Thu, 12 Apr 2012 14:22:57 GMT] [info] [<0.1393.0>] - - 'POST' /_session 401 We restarted couch several times using $ service couchdb restart but it was still impossible to login with an ordinary user. The problem was resolved by changing the log level to "debug" in local.ini and a restart. After this change the login and sign-up/in process in futon worked fine, and the already created user account worked fine. After changing the log level back to info the server continued to work fine. -- 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] [Created] (COUCHDB-1463) Do not return a 304 to a conditional view request when ?include_docs is specified
Do not return a 304 to a conditional view request when ?include_docs is
specified
-
Key: COUCHDB-1463
URL: https://issues.apache.org/jira/browse/COUCHDB-1463
Project: CouchDB
Issue Type: Bug
Components: View Server Support
Affects Versions: 1.1.1
Environment: Mac running Lion, Google Chrome browser for Mac
19.0.1084.15 beta
Running on CouchBase single server 2.0b which is CDB 1.1.X
Reporter: Ewan Makepeace
We are getting stale pages using views with the ?include_docs parameter as
follows:
1) Edit some document fields and save them (only fields not contained in either
view keys or values were changed)
2) Return to the list page driven by a view
3) Edits are not showing on the list page - displayed data is stale.
After investigation this seems to be due to caching of the view results in the
browser. If I flush the browser caches the stale data disappears. However I am
guessing that the browser makes a HEAD request for the URL to CouchDB and is
told that the cached view is good (since the view has not changed since last
access). However this is incorrect - the data returned by ?include_docs has
changed and so the cache is stale.
To reproduce:
1) Make a database called includedocs
2) Add a document such as:
{
"_id": "06d86659f684c5969d2f1bb5d201c274",
"_rev": "6-1bb578b525f1c24afe3f57b8271f843a",
"field1": 1,
"field2": 6
}
3) Add a simple view operating on field 1:
function(doc) {
emit("Field1", doc.field1);
}
4) Test the view: http://127.0.0.1:5984/includedocs/_design/field1/_view/field1
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1}
]}
5) Test with include docs:
http://127.0.0.1:5984/includedocs/_design/field1/_view/field1?include_docs=true
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"6-1bb578b525f1c24afe3f57b8271f843a","field1":1,"field2":6}}
]}
6) NOTE: Returned document has latest revision (6). Now edit the document
changing only Field2 so that the view is not affected:
{
"_id": "06d86659f684c5969d2f1bb5d201c274",
"_rev": "7-3e72418b297a1908820579f5506a4ec0",
"field1": 1,
"field2": 7
}
7) Refresh the View page from step 5:
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"6-1bb578b525f1c24afe3f57b8271f843a","field1":1,"field2":6}}
]}
8) NOTE: My view just returned stale data - revision is still 6. To confirm I
now compact my database and refresh the page again:
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"6-1bb578b525f1c24afe3f57b8271f843a","field1":1,"field2":6}}
]}
9) No change - the view is now returning deleted revisions. I flush my Chrome
Cache and refresh:
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"7-3e72418b297a1908820579f5506a4ec0","field1":1,"field2":7}}
]}
10) BINGO! The view is now returning the current document.
Looking in my CouchDB log I see lines like this:
[info] [<0.5140.11>] 127.0.0.1 - - GET
/includedocs/_design/field1/_view/field1?include_docs=true 304
while the last one shows
[info] [<0.5140.11>] 127.0.0.1 - - GET
/includedocs/_design/field1/_view/field1?include_docs=true 200
10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed,
but the document has not been modified, the server SHOULD respond with this
status code. The 304 response MUST NOT contain a message-body, and thus is
always terminated by the first empty line after the header fields.
So the browser does a conditional request, CouchDB says the data has not
changed but it has.
--
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] [Created] (COUCHDB-1462) Add Sharing / Reporting of CLI test results for further analysis
Add Sharing / Reporting of CLI test results for further analysis Key: COUCHDB-1462 URL: https://issues.apache.org/jira/browse/COUCHDB-1462 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Jan Lehnardt The browser based tests allowed to submit test results to a shared CouchDB instance, the CLI JS tests in 1.3/master don't do that yet. Also the etap tests don't do that either -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1461) replication timeout and loop
replication timeout and loop
Key: COUCHDB-1461
URL: https://issues.apache.org/jira/browse/COUCHDB-1461
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2, 1.3
Reporter: Benoit Chesneau
Attachments: test.py
When you try to do at the same time a replication in both way, it will timeout
then restart after 5s. Sometimes it won't be able to recover well. Adding a
sleep between 2 reps is possibly solving it but it shouldn't be needed.
Attached is a script using couchdbkit to reproduce the problem. SERVER_URI need
to be changed to point to your couchdb node.
Log:
> 09:09:24.016 [info] 127.0.0.1 - - HEAD /testdb1/ 404
09:09:24.028 [info] 127.0.0.1 - - PUT /testdb1/ 201
09:09:24.033 [info] 127.0.0.1 - - HEAD /testdb2/ 404
09:09:24.046 [info] 127.0.0.1 - - PUT /testdb2/ 201
09:09:24.071 [info] 127.0.0.1 - - GET
/_replicator/_all_docs?include_docs=true 200
09:09:28.110 [info] 127.0.0.1 - - PUT /_replicator/rep1 201
09:09:28.119 [info] 127.0.0.1 - - PUT /_replicator/rep2 201
09:09:28.121 [info] Attempting to start replication
`23280770e617f3a82f398b8eca09aaef` (document `rep1`).
09:09:28.123 [info] Attempting to start replication
`e42aaea4a0ceb931930834ecf7b79600` (document `rep2`).
09:09:28.169 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:09:28.172 [info] 127.0.0.1 - - GET /testdb2/ 200
09:09:28.176 [info] 127.0.0.1 - - GET
/testdb2/_local/e42aaea4a0ceb931930834ecf7b79600 404
09:09:28.179 [info] 127.0.0.1 - - GET
/testdb2/_local/f129a5531f82eb089a3e1ca9e80c9ad2 404
09:09:28.194 [info] Replication `"e42aaea4a0ceb931930834ecf7b79600"` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:09:28.196 [info] 127.0.0.1 - - GET
/testdb2/_changes?feed=normal&style=all_docs&since=0&heartbeat=1
200
09:09:28.202 [info] Document `rep2` triggered replication
`e42aaea4a0ceb931930834ecf7b79600`
09:09:28.203 [info] starting new replication
`e42aaea4a0ceb931930834ecf7b79600` at <0.262.0>
(`http://localhost:15984/testdb2/` -> `testdb1`)
09:09:28.208 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:09:28.212 [info] 127.0.0.1 - - GET /testdb2/ 200
09:09:28.218 [info] 127.0.0.1 - - GET
/testdb2/_local/23280770e617f3a82f398b8eca09aaef 404
09:09:28.219 [info] Replication `e42aaea4a0ceb931930834ecf7b79600`
finished (triggered by document `rep2`)
09:09:28.223 [info] 127.0.0.1 - - GET
/testdb2/_local/4b04e1e066f4ad1f988669036080ed9c 404
09:09:28.225 [info] Replication `"23280770e617f3a82f398b8eca09aaef"` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:09:58.203 [error] gen_server <0.287.0> terminated with reason: killed
09:09:58.207 [error] CRASH REPORT Process <0.287.0> with 0 neighbours
crashed with reason:
{killed,[{gen_server,terminate,6,[{file,"gen_server.erl"},{line,737}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}
09:09:58.215 [error] Error in replication
`23280770e617f3a82f398b8eca09aaef` (triggered by document `rep1`):
timeout
Restarting replication in 5 seconds.
09:10:03.223 [info] 127.0.0.1 - - HEAD /testdb2/ 200
09:10:03.227 [info] 127.0.0.1 - - GET /testdb2/ 200
09:10:03.231 [info] 127.0.0.1 - - GET
/testdb2/_local/23280770e617f3a82f398b8eca09aaef 404
09:10:03.235 [info] 127.0.0.1 - - GET
/testdb2/_local/4b04e1e066f4ad1f988669036080ed9c 404
09:10:03.237 [info] Replication `"23280770e617f3a82f398b8eca09aaef"` is using:
4 worker processes
a worker batch size of 500
20 HTTP connections
a connection timeout of 3 milliseconds
10 retries per request
socket options are: [{keepalive,true},{nodelay,false}]
09:10:03.244 [info] Document `rep1` triggered replication
`23280770e617f3a82f398b8eca09aaef`
09:10:03.245 [info] starting new replication
`23280770e617f3a82f398b8eca09aaef` at <0.335.0> (`testdb1` ->
`http://localhost:15984/testdb2/`)
09:10:03.253 [info] Replication `23280770e617f3a82f398b8eca09aaef`
finished (triggered by document `rep1`)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1460) Futon active tasks page fails with compaction tasks
Futon active tasks page fails with compaction tasks
---
Key: COUCHDB-1460
URL: https://issues.apache.org/jira/browse/COUCHDB-1460
Project: CouchDB
Issue Type: Bug
Components: Futon
Affects Versions: 1.2
Reporter: Dirkjan Ochtman
With this task:
[{"pid":"<0.586.0>","changes_done":69133,"database":"mail-djc","progress":35,"started_on":1333976136,"total_changes":192216,"type":"database_compaction","updated_on":1333976265}]
I see this in my browser's console:
[14:55:46.702] $("").find("th").text(task.type).end().find("td.object").text(task.task).end
is not a function @ http://localhost:5984/_utils/status.html:70
--
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] [Created] (COUCHDB-1459) Provide an option to build with the system yajl
Provide an option to build with the system yajl --- Key: COUCHDB-1459 URL: https://issues.apache.org/jira/browse/COUCHDB-1459 Project: CouchDB Issue Type: Improvement Components: Build System Affects Versions: 1.2 Reporter: Dirkjan Ochtman It should be possible to build with the system yajl instead of the bundled one through a --with-system-yajl configure option. -- 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] [Created] (COUCHDB-1458) --with-system-snappy
--with-system-snappy Key: COUCHDB-1458 URL: https://issues.apache.org/jira/browse/COUCHDB-1458 Project: CouchDB Issue Type: Improvement Components: Build System Affects Versions: 1.2 Reporter: Dirkjan Ochtman It should be possible to build CouchDB with the system snappy instead of the bundled one. -- 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] [Created] (COUCHDB-1457) Futon Test Suite failed on Windows 8 Consumer Preview
Futon Test Suite failed on Windows 8 Consumer Preview - Key: COUCHDB-1457 URL: https://issues.apache.org/jira/browse/COUCHDB-1457 Project: CouchDB Issue Type: Bug Components: Database Core, Futon, Test Suite Affects Versions: 1.2, 1.1.1 Environment: Windows 8 Consumer Preview Reporter: Chang Luo I have installed CouchDb 1.1.1 on Windows 8 Consumer Preview and most Futon test suite failed. It also failed for version 1.2. However, I am able to use futon to create database and documents. -- 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] [Created] (COUCHDB-1456) Various build issues with couched 1.2.0
Various build issues with couched 1.2.0 --- Key: COUCHDB-1456 URL: https://issues.apache.org/jira/browse/COUCHDB-1456 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1.1 Environment: CouchDB 1.2.0 / Solaris / gcc-4.2.3 / SpiderMonkey 1.8.5 Reporter: Victor Igumnov • Hard coded paths: /opt/local/(include|lib) can't be overridden using --libdir / --includedir • Fails to compile against spider monkey 1.8.5; CouchDB 1.1.1 did not have this issue. See build stdout below. gmake[4]: Entering directory `/software/work/apache-couchdb-1.2.0/src/couchdb/priv' /bin/sh ../../../libtool --tag=CC --mode=link gcc -g -Wall -Werror -D_BSD_SOURCE -I/opt/extra/include -DXP_UNIX -I/opt/extra/spidermonkey-1.8.5/include -I/opt/extra/spidermonkey-1.8.5/include/js -I/opt/extra/spidermonkey-1.8.5/include/mozjs -I/opt/local/include -I/usr/local/include -I/usr/include -O2 -g -O2 -L/opt/extra/spidermonkey-1.8.5/lib -L/opt/local/lib -L/usr/local/lib -L/opt/local/lib -L/usr/local/lib -o couchjs couchjs-http.o couchjs-main.o couchjs-utf8.o couchjs-util.o -L/opt/extra/lib -lcurl -L/opt/extra/lib -lssl -lcrypto -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz -lmozjs185-1.0 -lm-L/opt/local/lib -L/usr/local/lib -L/opt/local/lib -L/usr/local/lib libtool: link: gcc -g -Wall -Werror -D_BSD_SOURCE -I/opt/extra/include -DXP_UNIX -I/opt/extra/spidermonkey-1.8.5/include -I/opt/extra/spidermonkey-1.8.5/include/js -I/opt/extra/spidermonkey-1.8.5/include/mozjs -I/opt/local/include -I/usr/local/include -I/usr/include -O2 -g -O2 -o couchjs couchjs-http.o couchjs-main.o couchjs-utf8.o couchjs-util.o -L/opt/extra/spidermonkey-1.8.5/lib -L/opt/local/lib -L/usr/local/lib -L/opt/extra/lib /opt/extra/lib/libcurl.so -lssl -lcrypto -lsocket -lnsl -ldl -lz -lmozjs185-1.0 -lm -Wl,-rpath -Wl,/opt/extra/lib -Wl,-rpath -Wl,/opt/extra/lib /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o): In function `js::JSProxyHandler::~JSProxyHandler()': jsproxy.cpp:(.text+0x26f3): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o): In function `js::JSScriptedProxyHandler::~JSScriptedProxyHandler()': jsproxy.cpp:(.text+0x2732): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o):(.gnu.linkonce.d.rel.ro._ZTVN2js14JSProxyHandlerE+0x10): undefined reference to `__cxa_pure_virtual' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o):(.gnu.linkonce.d.rel.ro._ZTVN2js14JSProxyHandlerE+0x14): undefined reference to `__cxa_pure_virtual' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o):(.gnu.linkonce.d.rel.ro._ZTVN2js14JSProxyHandlerE+0x18): undefined reference to `__cxa_pure_virtual' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o):(.gnu.linkonce.d.rel.ro._ZTVN2js14JSProxyHandlerE+0x1c): undefined reference to `__cxa_pure_virtual' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o):(.gnu.linkonce.d.rel.ro._ZTVN2js14JSProxyHandlerE+0x20): undefined reference to `__cxa_pure_virtual' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jsproxy.o):(.gnu.linkonce.d.rel.ro._ZTVN2js14JSProxyHandlerE+0x24): more undefined references to `__cxa_pure_virtual' follow /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jswrapper.o): In function `JSWrapper::~JSWrapper()': jswrapper.cpp:(.text+0x2a92): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jswrapper.o): In function `JSCrossCompartmentWrapper::~JSCrossCompartmentWrapper()': jswrapper.cpp:(.text+0x2b42): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jstracer.o): In function `nanojit::LogControl::~LogControl()': jstracer.cpp:(.gnu.linkonce.t._ZN7nanojit10LogControlD0Ev+0x23): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jstracer.o): In function `js::DefaultSlotMap::~DefaultSlotMap()': jstracer.cpp:(.gnu.linkonce.t._ZN2js14DefaultSlotMapD0Ev+0x31): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(jstracer.o): In function `js::SlotMap::~SlotMap()': jstracer.cpp:(.gnu.linkonce.t._ZN2js7SlotMapD0Ev+0x31): undefined reference to `operator delete(void*)' /opt/extra/spidermonkey-1.8.5/lib/libmozjs185-1.0.a(Assembler.o):Assembler.cpp:(.gnu.linkonce.t._ZN7nanojit9LirFilterD0Ev+0x23): more undefined references to `operator delete(void*)' follow collect2: ld returned 1 exit status gmake[4]: *** [couchjs] Error 1 gmake[4]: Leaving directory `/software/work/apache-couchdb-1.2.0/src/couchdb/priv' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/software/work/apache-couchdb-1.2.0/src/couchdb' gmake[2]: *** [all-recursive] Error 1 gmake[2]
[jira] [Created] (COUCHDB-1455) Apache project branding requirements: DOAP file [PATCH]
Apache project branding requirements: DOAP file [PATCH] --- Key: COUCHDB-1455 URL: https://issues.apache.org/jira/browse/COUCHDB-1455 Project: CouchDB Issue Type: Task Components: Documentation Reporter: Shane Curcuru Attachments: doap_CouchDB.rdf Part of the Apache Project Branding requirements are having a DOAP file at http://projects.apache.org/create.html Sample DOAP for CouchDB attached. Thanks! -- 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] [Created] (COUCHDB-1454) server admin error on latest HEAD after PBKDF2 introduction
server admin error on latest HEAD after PBKDF2 introduction --- Key: COUCHDB-1454 URL: https://issues.apache.org/jira/browse/COUCHDB-1454 Project: CouchDB Issue Type: Bug Components: HTTP Interface, Test Suite Affects Versions: 1.3 Environment: erlang r15b, spidermonkey1.8.5 Reporter: Benoit Chesneau Attachments: test.log JS tests are failing since last introduction of PBKDF2: http://friendpaste.com/6ZjpPkJW3p6t26gARmbq1E -- 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] [Created] (COUCHDB-1453) Replicator fails with use_users_db = false
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
"source": "http://localhost:5990/users";,
"target": "users_backup",
"create_target": true,
"continuous": true
}
Creation of DB fails with:
"unauthorized to access or create database users_backup"
If I manually create this database, and set create_target to false, replication
completes, but generates errors while processing the update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`. Error:
`unauthorized`, reason: `You are not a db or server admin.`.
--
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] [Created] (COUCHDB-1452) Can't POST /_session with require_valid_user=true (Cookie authentication)
Can't POST /_session with require_valid_user=true (Cookie authentication)
-
Key: COUCHDB-1452
URL: https://issues.apache.org/jira/browse/COUCHDB-1452
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.1.1
Environment: Fedora 16
[root@CouchDBTest ~]# uname -a
Linux CouchDBTest 3.3.0-8.fc16.x86_64 #1 SMP Thu Mar 29 18:37:19 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
Reporter: Seb
Hello
I'm playing with couchdb and having a small problem with authentication (I
would like to be cookie+https only)
With require_valid_user, every action must be authenticated.
Then we need to authenticate to couchdb in order to POST to /_session.
So, if you disable classical HTTP auth, you can't authenticate users on couchdb
only with cookie.
[root@CouchDBTest ~]# curl -vX POST http://localhost:5984/_session -H
'Content-Type: application/x-www-form-urlencoded' -d
'name=admin&password=this_is_a_test'
* About to connect() to localhost port 5984 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> POST /_session HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0
> zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: localhost:5984
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 34
>
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm="administrator"
< Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
< Date: Sun, 01 Apr 2012 14:58:13 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 61
< Cache-Control: must-revalidate
<
{"error":"unauthorized","reason":"Authentication required."}
* Connection #0 to host localhost left intact
* Closing connection #0
The workaround to obtain a cookie with require_valid_user=true is to
authenticate with classical HTTP auth then to auth again with a POST on
_session.
Not POST /_session should be allowed even for require_valid_user=true ?
--
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] [Created] (COUCHDB-1451) Crash while finishing DB compaction on 1.2.x branch
Crash while finishing DB compaction on 1.2.x branch --- Key: COUCHDB-1451 URL: https://issues.apache.org/jira/browse/COUCHDB-1451 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.2 Environment: Ubuntu 10.04 LTS, Erlang R15B Reporter: Stefan Kögl I'm running a test instance of the CouchDB 1.2.x branch (not the current HEAD, though) and noticed a crash while finishing db compaction A log from the first failing request to the first that succeeds again: http://friendpaste.com/2Y3WoxTj1VKYAiaEa0pUVF -- 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] [Created] (COUCHDB-1450) having a member of _users create new users does not work
having a member of _users create new users does not work
Key: COUCHDB-1450
URL: https://issues.apache.org/jira/browse/COUCHDB-1450
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2
Environment: ubuntu 11.10
Reporter: paul iannazzo
instructions:
//create a server admin in futon {name:"paul",password:"password"}
//delete _users database
$.couch.signup({name:"admin"},"1")
//set _users security members names = ["admin"] via futon
//logout via futon
//login via futon as 'admin'
$.couch.signup({name:"user1"},"password",{success:function(){console.log(arguments)},error:function(){console.log(arguments)}})
//console output:
//PUT http://localhost:5984/_users/org.couchdb.user%3Auser1 404 (Object Not
Found)
//XHR finished loading: "http://localhost:5984/_users/org.couchdb.user%3Auser1";.
[404, "not_found", "missing"]
_users validation function is not even called in this situation.
i was told that the below link is related to the problem
https://github.com/apache/couchdb/blob/master/src/couchdb/couch_users_db.erl#L40
--
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] [Created] (COUCHDB-1449) Couchdb returns stopped status before process exits
Couchdb returns stopped status before process exits --- Key: COUCHDB-1449 URL: https://issues.apache.org/jira/browse/COUCHDB-1449 Project: CouchDB Issue Type: Bug Affects Versions: 1.1.1, 1.0.3, 1.2, 1.3 Environment: *NIX Reporter: Wendall Cada Fix For: 1.0.4, 1.2.1, 1.1.2 When restarting couchdb via init script, couchdb returns success status before the process is exited. When a start is issued before the process ends, couchdb fails to start, but returns success. -- 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] [Created] (COUCHDB-1448) Client Certificate Validation Nonfunctional
Client Certificate Validation Nonfunctional
---
Key: COUCHDB-1448
URL: https://issues.apache.org/jira/browse/COUCHDB-1448
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.2
Environment: OSX 10.7/Ubuntu 11.10, Erlang R15B/R14B4
Reporter: Brendan O'Connor
CouchDB commit: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 (from build-couchdb)
on both platforms (OSX / R14B4, and Ubuntu / R15B).
Attempting to use client SSL certificate validation. In local.ini, if I specify
cert_file and key_file, *server* SSL certificate functionality works as
expected. If I also specify a cacert_file and set verify_ssl_certificates =
true, I get the following crash:
[info] [<0.31.0>] Apache CouchDB has started on https://127.0.0.1:6984/
[error] [<0.165.0>] SSL: hello: ssl_handshake.erl:249:Fatal error: internal
error
=ERROR REPORT 23-Mar-2012::17:12:03 ===
SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
[error] [<0.164.0>] SSL: hello: ssl_handshake.erl:249:Fatal error: internal
error
=ERROR REPORT 23-Mar-2012::17:12:03 ===
SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
[error] [<0.166.0>] SSL: hello: ssl_handshake.erl:249:Fatal error: internal
error
=ERROR REPORT 23-Mar-2012::17:12:03 ===
SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
[error] [<0.145.0>] {error_report,<0.30.0>,
{<0.145.0>,std_error,
[{application,mochiweb},
"Accept failed error",
"{error,\"internal error\"}"]}}
=ERROR REPORT 23-Mar-2012::17:12:03 ===
application: mochiweb
"Accept failed error"
"{error,\"internal error\"}"
[error] [<0.144.0>] {error_report,<0.30.0>,
{<0.144.0>,std_error,
[{application,mochiweb},
"Accept failed error",
"{error,\"internal error\"}"]}}
=ERROR REPORT 23-Mar-2012::17:12:03 ===
application: mochiweb
"Accept failed error"
"{error,\"internal error\"}"
[error] [<0.145.0>] {error_report,<0.30.0>,
{<0.145.0>,crash_report,
[[{initial_call,
{mochiweb_acceptor,init,
['Argument__1','Argument__2','Argument__3']}},
{pid,<0.145.0>},
{registered_name,[]},
{error_info,
{exit,
{error,accept_failed},
[{mochiweb_acceptor,init,3,
[{file,
"/Users/ussjoin/Desktop/build-couchdb/dependencies/couchdb/src/mochiweb/mochiweb_acceptor.erl"},
{line,33}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,227}]}]}},
{ancestors,
[https,couch_secondary_services,couch_server_sup,
<0.31.0>]},
{messages,[]},
{links,[<0.142.0>]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,2584},
{stack_size,24},
{reductions,912}],
[]]}}
=CRASH REPORT 23-Mar-2012::17:12:03 ===
crasher:
initial call: mochiweb_acceptor:init/3
pid: <0.145.0>
registered_name: []
exception exit: {error,accept_failed}
in function mochiweb_acceptor:init/3
(/Users/ussjoin/Desktop/build-couchdb/dependencies/couchdb/src/mochiweb/mochiweb_acceptor.erl,
line 33)
ancestors: [https,couch_secondary_services,couch_server_sup,<0.31.0>]
messages: []
links: [<0.142.0>]
dictionary: []
trap_exit: false
status: running
heap_size: 2584
stack_size: 24
reductions: 912
neighbours:
[error] [<0.142.0>] {error_report,<0.30.0>,
{<0.142.0>,std_error,
{mochiweb_socket_server,310,
{acceptor_error,{error,accept_failed}
>From the browser side, the browser was never even asked by CouchDB to submit a
>client certificate; it crashes before it gets to that point.
Similar result when specifying ssl_trusted_certificates_file and
verify_ssl_certificates=true in the replicator section of default.ini; a crash
and nothing happens on replication attempts.
Workaround:
In replicator, specify cert_file and key_file, but leave
verify_ssl_certificates = false. Use nginx to verify the client certificates
(and serve server SSL if you wish). Re
[jira] [Created] (COUCHDB-1447) X-Couch-Update-NewRev header is missed if custom headers are specified in response of _update handler
X-Couch-Update-NewRev header is missed if custom headers are specified in
response of _update handler
-
Key: COUCHDB-1447
URL: https://issues.apache.org/jira/browse/COUCHDB-1447
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-a2bea1f-git
Apache CouchDB 1.2.0a-94e72e7-git
Reporter: Alexander Shorin
Priority: Minor
{
"_id": "_design/dump",
"_rev": "1-74b49af793bd5ce090712f638c3c920e",
"updates": {
"doc": "function(doc, req){ return [doc, {headers: {'Content-Type':
'text/html'}, 'body': 'test'}]}"
}
}
curl -v -X PUT http://localhost:5984/app%2fdefault/_design/dump/_update/doc/foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> PUT /app%2fdefault/_design/dump/_update/doc/foo HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.6
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 201 Created
< Server: CouchDB/1.3.0a-a2bea1f-git (Erlang OTP/R15B)
< Date: Mon, 19 Mar 2012 01:45:20 GMT
< Content-Type: text/html
< Content-Length: 13
<
* Connection #0 to host localhost left intact
test* Closing connection #0
{
"_id": "_design/dump",
"_rev": "2-f1c20db4fb28846399ab1cecaa9d2f28",
"updates": {
"doc": "function(doc, req){ return [doc, {'body': 'test'}]}"
}
}
curl -v -X PUT http://localhost:5984/app%2fdefault/_design/dump/_update/doc/foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> PUT /app%2fdefault/_design/dump/_update/doc/foo HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.6
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 201 Created
< X-Couch-Update-NewRev: 4-89c1c79a98fc269e474eb64d999a2049
< Server: CouchDB/1.3.0a-a2bea1f-git (Erlang OTP/R15B)
< Date: Mon, 19 Mar 2012 01:46:43 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 13
<
* Connection #0 to host localhost left intact
test* Closing connection #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] [Created] (COUCHDB-1446) Config settings input validation
Config settings input validation Key: COUCHDB-1446 URL: https://issues.apache.org/jira/browse/COUCHDB-1446 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.2 Reporter: Jason Smith Assignee: Jason Smith Priority: Minor Today I received a bug report from a user who thought CouchDB might be relaxing and evaluate an arithmetic expression in the config. (That makes sense, since it seems to evaluate erlang terms elsewhere.) https://getsatisfaction.com/iriscouch/topics/my_couchdb_is_broken_after_putting_a_badarg_for_a_configuration_value It would be nice for CouchDB to validate config input, particularly when bad values permanently take it offline. (In this case, it returns 500 for all subsequent requests.) IMO, a good bang-for-buck is to have three basic value types: 1. String 2. Erlang tuple 3. Integer And each setting knows what type it must be. -- 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] [Created] (COUCHDB-1445) CouchDB deletes .view files if it can't open them, even if the error is "emfile".
CouchDB deletes .view files if it can't open them, even if the error is
"emfile".
-
Key: COUCHDB-1445
URL: https://issues.apache.org/jira/browse/COUCHDB-1445
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2
Reporter: Jan Lehnardt
Fix For: 1.2
Via Stefan Kögl on dev@:
Another thing I noticed during my tests of CouchDB 1.2.x. I redirected
live traffic to the instance and after a rather short time, requests
were failing with the following information in the logs:
[Sun, 18 Mar 2012 16:39:24 GMT] [error] [<0.27554.2>]
{error_report,<0.31.0>,
{<0.27554.2>,std_error,
[{application,mochiweb},
"Accept failed error",
"{error,emfile}"]}}
[Sun, 18 Mar 2012 16:39:24 GMT] [error] [<0.27554.2>]
{error_report,<0.31.0>,
{<0.27554.2>,crash_report,
[[{initial_call,
{mochiweb_acceptor,init,
['Argument__1','Argument__2',
'Argument__3']}},
{pid,<0.27554.2>},
{registered_name,[]},
{error_info,
{exit,
{error,accept_failed},
[{mochiweb_acceptor,init,3},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_httpd,couch_secondary_services,
couch_server_sup,<0.32.0>]},
{messages,[]},
{links,[<0.129.0>]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,233},
{stack_size,24},
{reductions,244}],
[]]}}
I think "emfile" means that CouchDB (or mochiweb?) couldn't open any
more files / connections. I've set the (hard and soft) nofile limit for
user couchdb to 4096, but didn't raise the ERL_MAX_PORTS accordingly.
Anyway, as soon as the error occured, CouchDB started writing most of my
view files from scratch, rendering the instance unusable.
I'd expect CouchDB to fail more gracefully when the maximum number of
open files is reached. Is this a bug or expected behaviour?
--
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] [Created] (COUCHDB-1444) missing_named_view error on existing javascript design doc and view
missing_named_view error on existing javascript design doc and view
---
Key: COUCHDB-1444
URL: https://issues.apache.org/jira/browse/COUCHDB-1444
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Ubuntu 11.01 64 bit Erlang R13B03
Reporter: Sam Lown
Priority: Critical
Moved over from issue: https://issues.apache.org/jira/browse/COUCHDB-1225 which
has similar symptoms but the view is written in Erlang.
On our production server for no apparent reason, one of our views just suddenly
stopped responding to requests. The design document was still visible in Futon
and the "all" view did provide a list of documents. All other views in the ddoc
responded with a 404 {"error":"not_found","reason":"missing_named_view"}.
Restarting the couchdb server resolved the issue, and I've as yet been unable
to reproduce the problem.
Here is the last successful log entry for the view:
[Fri, 16 Mar 2012 13:14:19 GMT] [info] [<0.831.531>] 192.168.163.3 - -
'GET'
/maxi/_design/Payment/_view/by_journey_id_and_sequence?startkey=%5B%229bd1647eb09fca1634a8a6129a8cff46%22%2C%7B%7D%5D&endkey=%5B%229bd1647eb09fca1634a8a6129a8cff46%22%5D&limit=1&descending=true&include_docs=true&reduce=false
200
Many requests later to other documents and views, here is when requests stopped
working, some 6 minutes later:
[Fri, 16 Mar 2012 13:20:29 GMT] [info] [<0.4510.531>] 192.168.163.3 - -
'GET'
/maxi/_design/Payment/_view/by_user_id_and_created_at?startkey=%5B%22a0d0912e031b8fd28c2f89f828eebb12%22%5D&endkey=%5B%22a0d0912e031b8fd28c2f89f828eebb12%22%2C%7B%7D%5D&reduce=true&skip=0&limit=1
404
Here is the design document in question: https://gist.github.com/2050446
I could see nothing in the logs out of the ordinary.
Obviously, this problem is very alarming indeed and not something I've come
across before in CouchDB. As you can see the view in question is related to
Payments, which is something we really do not want to go wrong.
Please let me know if I can provide more information.
--
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] [Created] (COUCHDB-1443) Duplicate documents on concurrent insert
Duplicate documents on concurrent insert Key: COUCHDB-1443 URL: https://issues.apache.org/jira/browse/COUCHDB-1443 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.1.1 Reporter: Vladimir Petrukhin I started 15000 parallel connections to CouchDb and writing 1 doc per connection. I expected 15000 docs in CouchDb. But I get 15008 or 15014 or etc. I found that docs has different ids, but same content and revision. I use simple POST method to insert the docs. Not in batch mode. -- 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] [Created] (COUCHDB-1442) repeated rewriting overwrites the header thats supposed to store the orginal url for oauth
repeated rewriting overwrites the header thats supposed to store the orginal url for oauth -- Key: COUCHDB-1442 URL: https://issues.apache.org/jira/browse/COUCHDB-1442 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Ronny Pfannschmidt i think intead of mochiweb_headers:enter one needs to use mochiweb_headers:default for the x-couchdb-requested-path header in the rewrite handler -- 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] [Created] (COUCHDB-1441) _rewrite handler loops cause cpu load and swap of death
_rewrite handler loops cause cpu load and swap of death
---
Key: COUCHDB-1441
URL: https://issues.apache.org/jira/browse/COUCHDB-1441
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Environment: debian testing
Reporter: Ronny Pfannschmidt
when creating a simple _rewrite loop, the db will start to eat cpu and take
more & more memory
for testing i created:
{"_id":"_design/loopa","rewrites":[{"from":"","to":"../loopb/_rewrite"}]}
{"_id":"_design/loopb","rewrites":[{"from":"","to":"../loopa/_rewrite"}]}
accessing $dburi/_design/loopa/_rewrite/ will start the loop
--
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] [Created] (COUCHDB-1440) Permanent Erlang views not working on CouchDB 1.1.1
Permanent Erlang views not working on CouchDB 1.1.1
---
Key: COUCHDB-1440
URL: https://issues.apache.org/jira/browse/COUCHDB-1440
Project: CouchDB
Issue Type: Bug
Components: View Server Support
Affects Versions: 1.1.1
Environment: Microsoft Windows 7
Reporter: Nick Kitto
Erlang views are fully enabled and work when they are temporary views. When
they are saved into my design document via futon they no longer work.
An example view that I am trying to use is
fun ({Doc}) ->
case proplists:get_value(<<"doctype">>, Doc) of
<<"collections">> ->
Emit(proplists:get_value(<<"_id">>, Doc), {Doc});
_ ->
ok
end
end.
The copy inside the design document looks like this when it is saved from futon
or pushed using couchapp
"map": "fun ({Doc}) ->\r\n case proplists:get_value(<<\"doctype\">>, Doc)
of\r\n<<\"collections\">> ->\r\n Emit(proplists:get_value(<<\"_id\">>,
Doc), {Doc});\r\n_ ->\r\n ok\r\n end\r\nend."
When the view is run directly via the url (ie.
localhost:5984/couchapp/_design/jobs/_view/fields) there is no response inside
couch.log and nothing loads.
When the view is run in futon the error recieved is
Error: An error occurred accessing the view
no response
and it spits out a huge logfile
--
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] [Created] (COUCHDB-1439) `key`, `startkey`, `endkey` query parameters seems to have valid json value for show/update handlers.
`key`, `startkey`, `endkey` query parameters seems to have valid json value for
show/update handlers.
-
Key: COUCHDB-1439
URL: https://issues.apache.org/jira/browse/COUCHDB-1439
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-d6ab08d-git
Apache CouchDB 1.2.0a-0d8ddc8-git
Reporter: Alexander Shorin
CouchDB requires that values of query parameters with names: `key`, `startkey`,
`endkey` be valid json value when request been catched by show or update
handler. This behavior is expected for views and lists(as they works as proxy
for views and views requires this values as valid json ones), but it's little
surprising to see same behavior for shows and updates.
It's easy to test with any show or update handler:
~ # curl -X PUT http://localhost:5984/app/_design/ddoc -d '{"shows": {"empty":
"function(doc, req){return \"\"}"}, "updates": {"nothing": "function(doc,
req){return [null, \"\"]}"}}'
~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /app/_design/ddoc/_show/empty?key=foo HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
< Date: Tue, 13 Mar 2012 14:11:38 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 48
< Cache-Control: must-revalidate
<
{"error":"bad_request","reason":"invalid_json"}
* Connection #0 to host localhost left intact
* Closing connection #0
curl -v -X POST http://localhost:5984/app/_design/ddoc/_update/nothing?key=foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> POST /app/_design/ddoc/_update/nothing?key=foo HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
< Date: Tue, 13 Mar 2012 15:14:11 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 48
< Cache-Control: must-revalidate
<
{"error":"bad_request","reason":"invalid_json"}
* Connection #0 to host localhost left intact
* Closing connection #0
while...
~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=%22foo%22
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /app/_design/ddoc/_show/empty?key=%22foo%22 HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Vary: Accept
< Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
< Etag: "3B14BLTA7M1G53XKHX7EP0JUO"
< Date: Tue, 13 Mar 2012 14:12:20 GMT
< Content-Type: application/json
< Content-Length: 0
<
* Connection #0 to host localhost left intact
* Closing connection #0
Initially, I'd faced with such behavior only for `key` parameter. Digging
deeper I've found[1] same thing for `startkey` and `endkey` parameters, but
I've no idea how to explain their dependency well.
[1]
http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_httpd_external.erl;h=bfe77a329d569bcc48cb65d8251a437baf13fae6;hb=HEAD#l110
--
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] [Created] (COUCHDB-1438) GET /// triggers a 500 error
GET /// triggers a 500 error
Key: COUCHDB-1438
URL: https://issues.apache.org/jira/browse/COUCHDB-1438
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.2
Reporter: Jason Smith
Assignee: Jason Smith
Priority: Minor
I just noticed this.
$ curl -i http://localhost:5984//
HTTP/1.1 500 Internal Server Error
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Tue, 13 Mar 2012 08:48:46 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 53
Cache-Control: must-revalidate
{"error":"unknown_error","reason":"function_clause"}
That's weird. Usually CouchDB strips trailing slashes:
$ curl http://localhost:5984/x/
{"db_name":"x","doc_count":1,...}
$ curl http://localhost:5984/x/blah/
{"_id":"blah","_rev":"2-6c4b3bc6c2fdc5043139942dc6f1b994","_attachments":{"out.txt"
...
$ curl http://localhost:5984/x/blahout.txt///
Hello, world!
--
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] [Created] (COUCHDB-1437) Refactor configure.ac
Refactor configure.ac - Key: COUCHDB-1437 URL: https://issues.apache.org/jira/browse/COUCHDB-1437 Project: CouchDB Issue Type: Improvement Components: Build System Affects Versions: 1.3 Reporter: Paul Joseph Davis Working on COUCHDB-1426 today has made me hate life a little bit more. Our build system shouldn't be this complex. Mostly this has to do with us not using m4 in a way that doesn't lead to horrendous spaghetti code. New plan is to create a number of new files like: * m4/couch_erlang.m4 * m4/couch_icu_drv.m4 * m4/couch_js.m4 * m4/couch_snappy.m4 * m4/couch_windows.m4 (maybe? not sure how hard this will be to extract) Given these files the plan will be to make configure.ac just run a top-level macro from each file. Hopefully we can then have much cleaner definitions through out the configure stuff so that when something breaks it'll be more obvious why and where to look for an answer. -- 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] [Created] (COUCHDB-1436) Sometimes a newly created document does not appear in the database although operation for its creating returns "ok"=true
Sometimes a newly created document does not appear in the database although operation for its creating returns "ok"=true Key: COUCHDB-1436 URL: https://issues.apache.org/jira/browse/COUCHDB-1436 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.1 Reporter: Oleg Rostanin Sometimes after creating a document via http request a newly created document does not apper in the db (both in Web gui and when requested through API) althougho the response of the creation request returned ok=true, -- 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] [Created] (COUCHDB-1435) After removing _replicator documents replication is still running
After removing _replicator documents replication is still running - Key: COUCHDB-1435 URL: https://issues.apache.org/jira/browse/COUCHDB-1435 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.1 Reporter: Oleg Rostanin After removing _replicator documents replication is still running. Only restarting the service (under Windows) would help. -- 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] [Created] (COUCHDB-1434) Promise result
Promise result -- Key: COUCHDB-1434 URL: https://issues.apache.org/jira/browse/COUCHDB-1434 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Environment: All Reporter: Mike Coolin Priority: Minor For long running operations such as replicate error are generated due to the result taking loger that most browsers feel are acceptable. Instead of hacking the browser around this it would be better that the result is a polling result. This would allow the client to poll for the operations completion without causing timeout messages. As I see it: Command in couch would have to return a new code and message, immediately, perhaps a session/task id. The JS interface would need to be modified to poll for results and likely do a callback when complete. -- 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] [Created] (COUCHDB-1433) Linux mint 12
Linux mint 12 - Key: COUCHDB-1433 URL: https://issues.apache.org/jira/browse/COUCHDB-1433 Project: CouchDB Issue Type: Test Components: Test Suite Affects Versions: 1.2 Environment: 64 bit Mint 12 Reporter: Mike Coolin attachment_ranges failure 641ms Run with debugger Assertion failed: expected '"bytes 0-28/29"', got '"bytes 0-29/29"' Assertion failed: expected '"29"', got '"30"' Running tests in chrome, got many kill page offers especially on replication, which did complete successfully. It would be nice if the kill page options were handled better, I was about to kill the tests because I thought it was hung. -- 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] [Created] (COUCHDB-1432) [PULL REQUEST] Fix the benchmark script ./test/bench/run so it runs
[PULL REQUEST] Fix the benchmark script ./test/bench/run so it runs --- Key: COUCHDB-1432 URL: https://issues.apache.org/jira/browse/COUCHDB-1432 Project: CouchDB Issue Type: Bug Components: Build System Reporter: Adam Lofts Priority: Minor Please pull from: https://github.com/adamlofts/couchdb/tree/benchmark -- 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] [Created] (COUCHDB-1431) DDoc name with underscore as first char produce invalid filters
DDoc name with underscore as first char produce invalid filters
---
Key: COUCHDB-1431
URL: https://issues.apache.org/jira/browse/COUCHDB-1431
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-5cece68-git
Apache CouchDB 1.2.0a-0d8ddc8-git
Reporter: Alexander Shorin
CouchDB allows to create design document with id as `_design/_private`, but
there is no way to use filters from it:
$ curl -v http://localhost:5984/test/_changes?filter=_private/confidential
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /test/_changes?filter=_private/confidential HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: CouchDB/1.3.0a-5cece68-git (Erlang OTP/R14B04)
< Date: Wed, 07 Mar 2012 04:51:06 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 63
< Cache-Control: must-revalidate
<
{"error":"bad_request","reason":"unknown builtin filter name"}
* Connection #0 to host localhost left intact
* Closing connection #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] [Created] (COUCHDB-1430) init terminating in do_boot
init terminating in do_boot
---
Key: COUCHDB-1430
URL: https://issues.apache.org/jira/browse/COUCHDB-1430
Project: CouchDB
Issue Type: Question
Affects Versions: 0.10
Environment: Ubuntu 10.04 lts, ssh on 64bit opteron,
Reporter: Stephan Herrmann
Priority: Minor
Hi,
when calling couchdb I get the following error message:
"
sthe@theresa:~/openwns-sdk$ couchdb
Apache CouchDB 0.10.0 (LogLevel=info) is starting.
{"init terminating in
do_boot",{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},{erl_eval,do_apply,5},{erl_eval,exprs,5},{init,start_it,1},{init,start_em,1}]}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
"
How can I fix this? I'd add the erl_crash.dump if I knew where to add files
here.
Thanks,
Stephan
--
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] [Created] (COUCHDB-1429) Server stops responding after heavy load against _list function
Server stops responding after heavy load against _list function --- Key: COUCHDB-1429 URL: https://issues.apache.org/jira/browse/COUCHDB-1429 Project: CouchDB Issue Type: Bug Affects Versions: 1.1.1 Environment: Ubuntu 11.10 on AWS EC2 t1.micro instance, ~512MB memory and no swap Reporter: Nathan Vander Wilt Under heavy load, CouchDB crashes and stops responding to all incoming requests. To reproduce this, basically: 1. build-couchdb (1.1.1) on an EC2 t1.micro running Ubuntu 2. Add the '42' file at the path Blitz.io is looking for (not sure the easiest way to do this natively, I inserted a rule for it at the nginx level) 3. Run their default rush on a _list function (mine happened to do a fair amount of work, doing a Markdown conversion and Mustache templating) 4. Around about the 40 concurrent user mark in my case, CouchDB dies a terrible horrible death with a bunch of zombie couchjs process. In this log https://gist.github.com/a059c4db5bce19f1df7f (warning: large!) you'll see the heavy requests being handled but suddenly crashing. The "restart" seen at the end was due to manual intervention from the shell, CouchDB did not gracefully handle the issue. I later tried turning on some swap space in case memory was an issue, but didn't seem to have an appreciable effect. May be related to the discussion here: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201203.mbox/%3ccapino9ek5xajllpyufwnrk3hxkn5e-5j59pr6ummdwpmthh...@mail.gmail.com%3e -- 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] [Created] (COUCHDB-1428) Unexpected message, "{function_clause, [{[lists,ukeymerge2_2,..."
Unexpected message, "{function_clause, [{[lists,ukeymerge2_2,..."
--
Key: COUCHDB-1428
URL: https://issues.apache.org/jira/browse/COUCHDB-1428
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.2
Environment: Version: 1.2.0a-42b75f4-git [couchbase single server
build]
OS env: CentOS 5.7, 32bit
Other env info:
Running with snappy compression turned on and auto-compaction configured. Some
database are also compacted by the application code. There is a number of
continuous changes feeds running and there are continuous pull replications set
by other machines from this one.
Reporter: Nick Vatamaniuc
Saw the following lines in the log. Eventually server crashes and has to be
restarted.
[Sun, 04 Mar 2012 20:45:47 GMT] [info] [<0.1936.0>] 127.0.0.1 - - GET /wl_info
200
[Sun, 04 Mar 2012 20:45:47 GMT] [info] [<0.1854.0>] Starting compaction for db
"wl_info"
[Sun, 04 Mar 2012 20:45:47 GMT] [info] [<0.1936.0>] 127.0.0.1 - - POST
/wl_info/_compact 202
[Sun, 04 Mar 2012 20:45:47 GMT] [error] [<0.1568.0>] Unexpected message,
restarting couch_server: {'EXIT',
<0.1853.0>,
{function_clause,
[{lists,
ukeymerge2_2,
[1,
[{progress,
0},
{retry,
true},
{total_changes,
3}],
changes_done,
{changes_done,
0},
undefined,
[]]},
{lists,
ukeymerge,
3},
{couch_task_status,
update,
1},
{couch_db_updater,
copy_compact,
3},
{couch_db_updater,
start_copy_compact,
1}]}}
--
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] [Created] (COUCHDB-1427) Kept trying to run erratic replications half an hour after I'd deleted their docs from _replicator
Kept trying to run erratic replications half an hour after I'd deleted their
docs from _replicator
--
Key: COUCHDB-1427
URL: https://issues.apache.org/jira/browse/COUCHDB-1427
Project: CouchDB
Issue Type: Bug
Components: Futon, Replication
Affects Versions: 1.1.1
Environment: Windows 7 / 64bit
Reporter: Kurt Milam
Priority: Minor
Note: I did all of the following via the Futon interface on my local
development PC:
1. I added a doc with continuous=true and a user-defined ID to _replicator and
created a new, empty target database.
2. I realized shortly thereafter that my doc had an error.
2. I deleted the doc (after first being unable to edit/correct it) and deleted
the target database
3. I repaired and recreated the doc, using the same ID as in step #1, and I
created a new, empty target database
4. I probably did this a total of 4 times before I got the doc right (it was my
first replication doc working with a filter)
5. 10 minutes after I'd deleted the erratic docs, Couch was still trying to run
the replications
6. I deleted the correct doc, which had sparked a successful replication
7. Half an hour later, Couch was still trying to run all of the unsuccessful
replications, logging errors at the rate of around 20K lines per minute
8. I finally restarted Couch - after it came back up, it no longer tried to run
the replications
Following are a few representative log entries:
[Fri, 02 Mar 2012 18:10:54 GMT] [info] [<0.13674.364>] Document `example_john`
triggered replication `10654d1361b111fb7c7f53b05f15mastercb+continuous`
[Fri, 02 Mar 2012 18:10:54 GMT] [info] [<0.13626.364>] starting new replication
"10654d1361b111fb7c7f53b05f15mastercb+continuous" at <0.13674.364>
[Fri, 02 Mar 2012 18:10:55 GMT] [error] [<0.13676.364>] OS Process Error
<0.13683.364> :: {<<"unnamed_error">>,
<<"(new
String(\"Please provide a query parameter `name`.\"))">>}
[Fri, 02 Mar 2012 18:10:55 GMT] [error] [<0.13675.364>] changes_loop died with
reason {{nocatch,
{<<"unnamed_error">>,
<<"(new
String(\"Please provide a query parameter `name`.\"))">>}},
[{couch_os_process,
prompt,2},
{couch_query_servers,
with_ddoc_proc,2},
{couch_query_servers,
filter_docs,5},
{couch_changes,
'-os_filter_fun/4-fun-1-',
6},
{couch_changes,
changes_enumerator,2},
{couch_btree,
stream_kv_node2,8},
{couch_btree,
stream_kp_node,7},
{couch_btree,
stream_kp_node,8}]}
[Fri, 02 Mar 2012 18:10:55 GMT] [error] [emulator] Error in process
<0.13676.364> with exit value: {{nocatch,{<<13 bytes>>,<<64
bytes>>}},[{couch_os_process,prompt,2},{couch_query_servers,with_ddoc_proc,2},{couch_query_servers,filter_docs,5},{couch_changes,'-os_filter_fun/4-fun-1-',6},{couch_changes,changes_enumerator,2},{couch_btree,stream_kv_node2...
[Fri, 02 Mar 2012 18:10:55 GMT] [error] [<0.13675.364>] ** Generic server
<0.13675.364> terminating
** Last message in was {'EXIT',<0.13676.364>,
{{nocatch,
{<<"unnamed_error">>,
<<"(new String(\"Please provide a query
parameter `name`.\"))">>}},
[{couch_os_process,prompt,2},
{couch_query_servers,with_ddoc_proc,2},
{couch_query_servers,filter_docs,5},
{couch_changes,'-os_filter_fun/4-fun-1-'
[jira] [Created] (COUCHDB-1426) error while building with 2 spidermonkey installed
error while building with 2 spidermonkey installed -- Key: COUCHDB-1426 URL: https://issues.apache.org/jira/browse/COUCHDB-1426 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1.1, 1.2 Reporter: Benoit Chesneau Context: To bench the differences between different versions of couchdb I had to test against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in /usr/local while the 1.7 version is installed on a temporary path. Problem: Using --witth-js-include & --with-js-lib configure options aren't enough to use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing js-config from the path doesn't change anything. I had to uninstall spidermonkey 1.8.5 to have these setting working. Error result: $ ./configure --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include --with-js-include=/Users/benoitc/local/js-1.7.0/include --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... i386-apple-darwin11.3.0 checking host system type... i386-apple-darwin11.3.0 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm checking the name lister (/usr/bin/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm output from gcc object... ok checking for dsymutil... dsymutil checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common -DPIC checking if gcc PIC flag -fno-common -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin11.3.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking whether ln -s works... yes checking for pthread_create in -lpthread... yes checking for JS_NewContext in -lmozjs185... yes checking jsapi.h usability... yes checking jsapi.h presence... yes checking for jsapi.h... yes checking whether JSOPTION_ANONFUNFIX is declared... no configure: error: Your SpiderMonkey library is too new. Versions of SpiderMonkey after the js185-1.0.0 release remove the optional enforcement of preventing anonymous functions in a statement context. This
[jira] [Created] (COUCHDB-1425) Emitting UTF-8 chars >= 0xD800 in JS map stops design doc from indexing
Emitting UTF-8 chars >= 0xD800 in JS map stops design doc from indexing --- Key: COUCHDB-1425 URL: https://issues.apache.org/jira/browse/COUCHDB-1425 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.1.1 Environment: Mac OS 10.6.8, but not sure that matters. Reporter: Jim Klo Was trying determine UTF-8 Char collation, using the following Gist: https://gist.github.com/1904807 It turns out that once the view gets to the document that would emit "\uD800", the view server times out and stops indexing that design document. This seems like a bug, since I can 'store' a document with UTF-8 chars >= 0xD800, but one cannot emit a key with that char in the string. -- 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] [Created] (COUCHDB-1424) make check hangs when compiling with R15B
make check hangs when compiling with R15B - Key: COUCHDB-1424 URL: https://issues.apache.org/jira/browse/COUCHDB-1424 Project: CouchDB Issue Type: Bug Components: Test Suite Affects Versions: 1.2, 1.3 Reporter: Jan Lehnardt make check hangs when running under R15B. For me it is 160-vhosts.t where execution stops, but if I recall correctly others have reported other tests. The crux here is that running the tests individually succeeds. -- 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] [Created] (COUCHDB-1423) Peer not set by X-Forwarded-For when using IPv6
Peer not set by X-Forwarded-For when using IPv6 --- Key: COUCHDB-1423 URL: https://issues.apache.org/jira/browse/COUCHDB-1423 Project: CouchDB Issue Type: Bug Reporter: Nathan Vander Wilt Priority: Minor CouchDB transparently handles an X-Forwarded-For header, using the actual client value for the request's "peer" property and logging (albeit modulo [#COUCHDB-1421]). However this does not seem to be working with IPv6 connections. When bound on 0.0.0.0 `curl -H "X-Forwarded-For: 123.45.6.7" localhost:5984` logs a peer address of 123.45.6.7. But when bound on :: the same request logs :::127.0.0.1 -- 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] [Created] (COUCHDB-1422) Let _show/_list functions prevent caching
Let _show/_list functions prevent caching
-
Key: COUCHDB-1422
URL: https://issues.apache.org/jira/browse/COUCHDB-1422
Project: CouchDB
Issue Type: Bug
Reporter: Nathan Vander Wilt
Priority: Minor
While CouchDB's automatic ETag handling on Show/List functions is desirable 95%
of the time, I keep running into situations where I want to do something handy
in a documentless show function ("if all you have is a hammer...") but end up
getting into trouble with cached responses.
I think the most straightforward fix is to send along any ETag header in a
viewserver response instead of the default. Currently, instead of *overriding*
the ETag header, the two headers are combined. This does "bust the cache" in
some browsers if the only attempt to revalidate the first one (which happens to
be that of the show function), but Firefox at least sends both back and CouchDB
finds its match and responds with 304 "Not Modified". Letting a show/list
function return a single garbage ETag would let it avoid having its result
considered so strongly valid later.
Consider my stupid simple little public IP address reflector
(https://github.com/natevw/ipcalf/blob/master/shows/address.js) or the
following show:
function (doc, req) {
return "Now is " + Date() + " and here is a unique identifier " +
req.uuid + " which might have more entropy than " + Math.random();
}
There are a lot of interesting/fun things that are well within JavaScript's
reach in a (practically) side-effect free formatting function: different
stylesheet based on user agent, SVG chart of DB stats in req.info, random quote
generator... None of these are practical if the response will quickly end up
locked by a cache — potentially in proxies well upstream of the client — based
on an overly narrow definition (and IMO sometimes needless requirement) of
idempotence.
Letting the show function "bust the cache" by providing a response ETag which
CouchDB won't re-validate would be a simple way to avoid this. With my proposal
above, my IP address example would simply override the ETag and avoid
304-effects altogether:
function (doc, req) {
return {headers:{ETag:'"'+req.uuid+'"'}, body: "Your IP address is: " +
req.peer};
}
[If such a function wanted to allow for some caching benefit, it could provide
an appropriate Expires header instead.]
--
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] [Created] (COUCHDB-1421) Wrong X-Forwarded-For address chosen as "peer"?
Wrong X-Forwarded-For address chosen as "peer"? --- Key: COUCHDB-1421 URL: https://issues.apache.org/jira/browse/COUCHDB-1421 Project: CouchDB Issue Type: Bug Reporter: Nathan Vander Wilt I noticed that in the Mochiweb code, it uses the last item of the X-Forwarded-For list as the peer: https://github.com/apache/couchdb/blob/master/src/mochiweb/mochiweb_request.erl#L82 But shouldn't this snag the *first* item of the list instead? http://tools.ietf.org/html/draft-petersson-forwarded-for-02#section-5.2 says "the first for-parameter will disclose the user agent where the request first was made" — the user agent is what I'd want as an app developer, not the second-nearest proxy. -- 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] [Created] (COUCHDB-1420) Futon display breaks on really long db name
Futon display breaks on really long db name --- Key: COUCHDB-1420 URL: https://issues.apache.org/jira/browse/COUCHDB-1420 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.2 Reporter: Sam Bisbee Priority: Minor Futon's display breaks if the database name is too long and some information is just not retrieved. Example database name: bpjwguulsnozjugktpmtnsucxlojprxyhbmuxkyuqepaptmjvwctautgpiawxiodsqkdrposfrdayauvzkgixkztdaamhhihifdvdqykpqacpmifosdouzlqwxkbooxnebxohdueppgpawfsetsayrzeigevclmnplfewskbzepwqkrpuvsqeqkdnmkgxwrsmdqmgcqkhfkgtnfmcompyugwmymaoguzxwfjn Marking minor since people who want db names this long/crazy are (a) a minority and (b) should be accepting of minor UI issues. Cheers. -- 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] [Created] (COUCHDB-1419) bail if g++ isn't found or use gcc for spidermonkey checks in ./configure
bail if g++ isn't found or use gcc for spidermonkey checks in ./configure - Key: COUCHDB-1419 URL: https://issues.apache.org/jira/browse/COUCHDB-1419 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1, 1.2, 1.3 Reporter: Jan Lehnardt it seems we don't bail out of ./configure if g++ isn't installed, but the ./configure checks for SpiderMonkey require g++ and report Spidermonkey not found, although it is g++ that is missing -- 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] [Created] (COUCHDB-1418) make -j builds can cause build error with help2man
make -j builds can cause build error with help2man -- Key: COUCHDB-1418 URL: https://issues.apache.org/jira/browse/COUCHDB-1418 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1, 1.2, 1.3 Reporter: Jan Lehnardt Assignee: Noah Slater Priority: Minor make -jN enables parallel execution of build tasks. When a system has help2man installed, the build system might invoke couchjs -h to generate the help before the couchjs binary was finished building. Subsequent runs of make -jN or make without the -jN option succeed as usual. -- 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] [Created] (COUCHDB-1417) Running individual JS tests at the CLI fails
Running individual JS tests at the CLI fails Key: COUCHDB-1417 URL: https://issues.apache.org/jira/browse/COUCHDB-1417 Project: CouchDB Issue Type: Bug Components: Test Suite Affects Versions: 1.2 Reporter: Jason Smith Priority: Minor Running the following in the 1.2.x branch does not work: $ ./test/javascript/run share/www/script/test/rewrite.js [couchjs] Error: No XMLHTTPRequest support detected The cause is that the runner concatenates several files into one script: cat couchdb/share/www/script/json2.js couchdb/share/www/script/sha1.js couchdb/share/www/script/oauth.js couchdb/share/www/script/couch.js couchdb/share/www/script/couch_test_runner.js couchdb/share/www/script/couch_tests.js share/www/script/test/rewrite.js couchdb/test/javascript/couch_http.js couchdb/test/javascript/cli_runner.js If the final statement before couch_http.js is missing a semicolon, then couch_http.js will look like a function invocation. The fix is to modify couch_http.js to be completely protected from whatever statements may have preceded 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] [Created] (COUCHDB-1416) the requested_path that is passed to a show is wrong on a vhost with a path
the requested_path that is passed to a show is wrong on a vhost with a path Key: COUCHDB-1416 URL: https://issues.apache.org/jira/browse/COUCHDB-1416 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Ryan Ramage Priority: Minor In a show or list, it is impossible to construct a full url that an end user could use to re-request the resource, given the various combinations of vhosts and rewrites. The major one is if the vhost contains a path component, this path information is not passed to the show at all. I have created three tests that highlight the condition, currently failing for one test, with the two passing to prevent regressions. The commit can be found here: https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60 I have talked this over with JasonSmith and bennoitc on #couchdb and they asked me to write the tests and raise the jira. -- 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] [Created] (COUCHDB-1415) Re-insering a document silently fails after compact is executed
Re-insering a document silently fails after compact is executed
---
Key: COUCHDB-1415
URL: https://issues.apache.org/jira/browse/COUCHDB-1415
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Tested on multiple linux platforms
Reporter: Viktor Szabo
When a document is re-inserted after a compact operation using the same
contents it was originally created, the insert operation is silently ignored,
leaving the client unaware of the fact it's document is not available in the
database.
Can be reproduced using the following sequence of steps:
alias curl='curl -H "Content-Type: application/json"'
url="http://localhost:5984/database";
1 curl -X PUT $url
2 curl -X POST $url -d '{"_id": "bug", "key": "value"}'
3 curl -X DELETE "$url/bug?rev=1-59414e77c768bc202142ac82c2f129de"
4 curl -X POST "$url/_compact"
5 curl -X POST $url -d '{"_id": "bug", "key": "value"}'
6 curl -X GET "$url/bug"
(bug here)
1 {"ok":true}
201
2 [{"ok":true,"id":"bug","rev":"1-59414e77c768bc202142ac82c2f129de"}]
201
3 {"ok":true,"id":"bug","rev":"2-9b2e3bcc3752a3a952a3570b2ed4d27e"}
200
4 {"ok":true}
202
5 [{"ok":true,"id":"bug","rev":"1-59414e77c768bc202142ac82c2f129de"}]
201
6 {"error":"not_found","reason":"deleted"}
404
CouchDB shouldn't report "ok" on step 5 and then go on to claim that the doc is
deleted. Also, it seems to work on second try:
7 curl -X POST $url -d '{"_id": "bug", "key": "value"}'
8 curl -X GET "$url/bug"
7 {"ok":true,"id":"bug","rev":"3-674f864b73df1c80925e48436e21d550"}
201
8 {"_id":"bug","_rev":"3-674f864b73df1c80925e48436e21d550","key":"value"}
200
--
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] [Created] (COUCHDB-1414) Unicode characters' slash is escaped when entering into a single field
Unicode characters' slash is escaped when entering into a single field -- Key: COUCHDB-1414 URL: https://issues.apache.org/jira/browse/COUCHDB-1414 Project: CouchDB Issue Type: Bug Components: Futon Environment: Tested in Chromium 18 Reporter: Sam Bisbee Priority: Minor The Problem: When entering a Unicode character into a document with Futon's Fields view (not whole doc) the back slash is escaped, thereby breaking the Unicode character. This does not happen in the Source view. Steps to Reproduce: 1. Create or open a document. 2. Add "\u2708" to the value of a field. 3. Save the document. Expected Result: The field's value should be "\u2708" Actual Result: The field's value is "\\u2708" -- 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] [Created] (COUCHDB-1413) Reduce queries with ?inclusive_end=false and endkey/endkey_docid or startkey/startkey_docid (if ?descending=true) produce incorrect reductions
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 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] [Created] (COUCHDB-1412) "Temporary Views" heading nested incorrectly in doc wiki
"Temporary Views" heading nested incorrectly in doc wiki Key: COUCHDB-1412 URL: https://issues.apache.org/jira/browse/COUCHDB-1412 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Nathan Vander Wilt Priority: Trivial The "View Compaction" heading is one level too deep in the wiki: http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction It appears as a subsection of "View Compaction" and doesn't appear in the top TOC widget. Easy fix for someone, or I'd be happy to get contrib access to the wiki (NathanVanderWilt). -- 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] [Created] (COUCHDB-1411) futon breaking in chrome and throwing errors in firefox after editing _security for a DB
futon breaking in chrome and throwing errors in firefox after editing _security
for a DB
Key: COUCHDB-1411
URL: https://issues.apache.org/jira/browse/COUCHDB-1411
Project: CouchDB
Issue Type: Bug
Components: Futon
Affects Versions: 1.1.1
Environment: chrome, firefox
Reporter: paul iannazzo
this situation happens when i edit the security object of my db. i change the
roles for readers to ["_admin"].
then back to [].
futon can not load my documents after the first change, and second.
now when i click on my db in the overview, the url that it loads is
..._utils/database.html?install/_security
i also get a pop-up error, and futon does not render any of my documents (blank
list)
chrome console log:
GET http://192.168.1.254:5984/_config/query_servers/ 401 (Unauthorized)
jQuery.extend.ajaxjquery.js:5252
ajaxjquery.couch.js:636
$.extend.configjquery.couch.js:62
$.extend.CouchDatabasePage.populateLanguagesMenufuton.browse.js:345
$.extend.CouchDatabasePage.populateViewEditorfuton.browse.js:309
(anonymous function)database.html:92
jQuery.extend.readyjquery.js:392
DOMContentLoaded
XHR finished loading:
"http://192.168.1.254:5984/install/_all_docs?startkey=%22_design%2F%22&endkey=%22_design0%22&include_docs=true";.
jQuery.extend.ajaxjquery.js:5252
ajaxjquery.couch.js:636
$.extend.db.allDocsjquery.couch.js:310
$.extend.CouchDatabasePage.populateViewsMenufuton.browse.js:366
(anonymous function)database.html:91
jQuery.extend.readyjquery.js:392
DOMContentLoadedjquery.js:745
GET
http://192.168.1.254:5984/install/_design/undefined/_view/undefined?limit=11
404 (Object Not Found)
jQuery.extend.ajaxjquery.js:5252
ajaxjquery.couch.js:636
$.extend.db.viewjquery.couch.js:532
$.extend.CouchDatabasePage.updateDocumentListingfuton.browse.js:785
$.extend.CouchDatabasePage.populateViewEditorfuton.browse.js:307
(anonymous function)database.html:92
jQuery.extend.readyjquery.js:392
DOMContentLoaded
the GET 'install/_design/undefined/_view/undefined' doesn't make sense to me
on firefox console i get:
http://192.168.1.254:5984/_config/query_servers/
401 Unauthorized 89ms
jquery.js?1.4.2 (line 5252)
HeadersResponseJSON
{"error":"unauthorized","reason":"You are not a server admin."}
firefox does not give me a pop-up error and other than the console error things
seem to work as normal
--
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] [Created] (COUCHDB-1410) Formally define number support
Formally define number support -- Key: COUCHDB-1410 URL: https://issues.apache.org/jira/browse/COUCHDB-1410 Project: CouchDB Issue Type: Improvement Affects Versions: 1.2 Reporter: Robert Newson Priority: Blocker Fix For: 1.3 The JSON spec has a very loose definition of Number. CouchDB, as a database, should have well-defined and first class support for numbers (both integral and decimal). The precision of number support should be formally specified as should the algorithm used to represent floating-point values, especially where an approximation must be made in the conversion. -- 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] [Created] (COUCHDB-1409) Look into manual GC
Look into manual GC --- Key: COUCHDB-1409 URL: https://issues.apache.org/jira/browse/COUCHDB-1409 Project: CouchDB Issue Type: Improvement Reporter: Jan Lehnardt This just as a reminder to consider http://andy.wordpress.com/2012/02/13/erlang-is-a-hoarder/ (incl. comments) -- 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] [Created] (COUCHDB-1408) Could I request write access to the wiki please?
Could I request write access to the wiki please? Key: COUCHDB-1408 URL: https://issues.apache.org/jira/browse/COUCHDB-1408 Project: CouchDB Issue Type: Wish Components: Documentation Reporter: Roger Moffatt Priority: Trivial I'd like to make some minor corrections to the Mac OSX documentation on the wiki, I've found the install process a bit painful and had to hunt around for some solutions that I'd like to point out in the wiki directly. My wiki account is RogerMoffatt. Alternatively, could someone please add a note to the homebrew section that this issue https://github.com/mxcl/homebrew/issues/7024 seems to affect current OS X Lion installs and the solution is to kill the final make with ctrl-c and then run brew install -v couch. -- 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] [Created] (COUCHDB-1407) JSON encoding of number changes
JSON encoding of number changes
---
Key: COUCHDB-1407
URL: https://issues.apache.org/jira/browse/COUCHDB-1407
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.2
Environment: Ubuntu 12.04 (alpha)
Reporter: Adam Lofts
JSON encoding of Number has changed from 1.0.2 to 1.2. JSON only defines Number
but this change causes issues in my app because python decodes the number as an
int in 1.2.
Test case:
PORT=5985
curl -X DELETE http://localhost:$PORT/test-floats/
curl -X PUT http://localhost:$PORT/test-floats/
curl -X PUT http://localhost:$PORT/test-floats/doc1 -H "Content-Type:
application/json" -d "{ \"a\": 1.0 }"
curl http://localhost:$PORT/test-floats/doc1
Run against 1.0.2:
{"ok":true}
{"ok":true}
{"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
{"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1.0}
Run against 1.2:
{"ok":true}
{"ok":true}
{"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
{"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1}
--
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] [Created] (COUCHDB-1406) PUTing JSON with invalid UTF-8 returns no error message
PUTing JSON with invalid UTF-8 returns no error message
Key: COUCHDB-1406
URL: https://issues.apache.org/jira/browse/COUCHDB-1406
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1.1
Environment: Debian testing
Reporter: Sam Vevang
Priority: Minor
I'm reading utf-8 documents from disk and embedding them in a json structure.
Several of them contain invalid utf-8 characters. If I PUT to couchdb I get a
stack trace in my debug log and the tcp connection is dropped--no http code is
returned
[Wed, 08 Feb 2012 17:58:55 GMT] [error] [<0.28906.4>] {error_report,<0.31.0>,
{<0.28906.4>,crash_report,
[[{initial_call,
{mochiweb_acceptor,init,
['Argument__1','Argument__2','Argument__3']}},
{pid,<0.28906.4>},
{registered_name,[]},
{error_info,
{exit,
{ucs,{bad_utf8_character_code}},
[{xmerl_ucs,from_utf8,1,
[{file,"xmerl_ucs.erl"},{line,185}]},
{mochijson2,json_encode_string,2,
[{file,"mochijson2.erl"},{line,148}]},
{mochijson2,'-json_encode_proplist/2-fun-0-',3,
[{file,"mochijson2.erl"},{line,129}]},
{lists,foldl,3,[{file,"lists.erl"},{line,1197}]},
{mochijson2,json_encode_proplist,2,
[{file,"mochijson2.erl"},{line,132}]},
{couch_httpd,send_json,4,
[{file,"couch_httpd.erl"},{line,635}]},
{couch_httpd,handle_request_int,5,
[{file,"couch_httpd.erl"},{line,272}]},
{mochiweb_http,headers,5,
[{file,"mochiweb_http.erl"},{line,126}]}]}},
{ancestors,
[couch_httpd,couch_secondary_services,
couch_server_sup,<0.32.0>]},
{messages,[]},
{links,[<0.113.0>,#Port<0.30990>]},
{dictionary,
[{mochiweb_request_body,
<<"{\"id\":111,\"doc\":\"ker\\u0019 u\"}\n">>},
{mochiweb_request_qs,[]},
{mochiweb_request_recv,true},
{jsonp,no_jsonp},
{mochiweb_request_cookie,[]}]},
{trap_exit,false},
{status,running},
{heap_size,2584},
{stack_size,24},
{reductions,7048}],
[]]}}
--
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] [Created] (COUCHDB-1405) error generating document id with utc_random
error generating document id with utc_random Key: COUCHDB-1405 URL: https://issues.apache.org/jira/browse/COUCHDB-1405 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.1.1 Environment: Windows 7, 64-bit, running as virtual pc in hyper-v Reporter: André Bögge I use the utc_random algorithm for generating document ids. So it's possible for me to calculate time and date out of the id in my client application. After running CouchDB for about a month i got a difference between system time and calculated time of id of about half an hour. I restarted the database and even then i got a difference about 1 minute. -- 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] [Created] (COUCHDB-1404) How to password protect couchdb web interface (futon)?
How to password protect couchdb web interface (futon)?
--
Key: COUCHDB-1404
URL: https://issues.apache.org/jira/browse/COUCHDB-1404
Project: CouchDB
Issue Type: Bug
Components: Futon
Affects Versions: 0.10.1
Environment: Linux / Unix
Reporter: arturo gomez
The server is running the following version of couchdb:
{"couchdb":"Welcome","version":"0.10.1"}
And currently the futon web interface can be accessed by the public. Is there a
way of password protecting the futon web interface? Would it be possible to use
an htpasswd file using htaccess?
I look forward to hearing from you soon. Thanks
--
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] [Created] (COUCHDB-1403) Multipart upload fails with exception if request body is chunked
Multipart upload fails with exception if request body is chunked
Key: COUCHDB-1403
URL: https://issues.apache.org/jira/browse/COUCHDB-1403
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1.1
Environment: Mac OS X 10.7.3, Couchbase Single Server 2.0.0dev4 (based
on CouchDB 1.1.1)
Reporter: Jens Alfke
Priority: Minor
CouchDB doesn't correctly parse MIME multipart PUT/POST requests when the HTTP
transfer is chunked. It generates an Erlang exception, and the client sees that
the socket was closed unexpectedly.
[error] [emulator] Error in process <0.15079.3> with exit value:
{badarith,[{couch_httpd_db,'-receive_request_data/2-fun-0-',3},{couch_httpd,read_until,3},{couch_httpd,parse_part_body,1},{couch_httpd,parse_multipart_request,3},{couch_doc,'-doc_from_multi_part_stream/2-fun-1-'...
The source looks like:
receive_request_data(Req) ->
receive_request_data(Req, couch_httpd:body_length(Req)).
receive_request_data(Req, LenLeft) when LenLeft > 0 ->
Robert Newson commented on the user@ list: "Pretty obvious bug, yes. We're
attempting to evaluate whether the atom 'chunked' is greater than zero."
The obvious workaround -- don't use chunked -- may not be available to clients.
This level of encoding is generally performed by the browser or client HTTP
library, and the app level code may not have control over whether it's
performed.
--
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] [Created] (COUCHDB-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
--
Key: COUCHDB-1402
URL: https://issues.apache.org/jira/browse/COUCHDB-1402
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Windows Server 2003 R2 SP3
Reporter: Christopher Betz
Every time I go to access a view, I get this error, even from futon. I am
currently running Windows 2003 Server R3, SP3.
** Reason for termination ==
** {'EXIT',
{{badmatch,
{error,
{enoent,
[{erlang,open_port,
[{spawn,
"c:/PROGRA~1/Apache Software
Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe
../share/couchdb/server/main.js"},
[stream,{line,1024},binary,exit_status,hide]]},
{couch_os_process,init,1},
{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}}},
[{couch_query_servers,new_process,3},
{couch_query_servers,lang_proc,3},
{couch_query_servers,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}}
[Mon, 06 Feb 2012 18:59:17 GMT] [error] [<0.19625.0>] {error_report,<0.34.0>,
{<0.19625.0>,crash_report,
[[{initial_call,{couch_file,init,['Argument__1']}},
{pid,<0.19625.0>},
{registered_name,[]},
{error_info,
{exit,
{'EXIT',
{{badmatch,
{error,
{enoent,
[{erlang,open_port,
[{spawn,
"c:/PROGRA~1/Apache Software
Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe
../share/couchdb/server/main.js"},
[stream,
{line,1024},
binary,exit_status,hide]]},
{couch_os_process,init,1},
{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}}},
[{couch_query_servers,new_process,3},
{couch_query_servers,lang_proc,3},
{couch_query_servers,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}},
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,[<0.19624.0>,<0.19623.0>]},
{messages,[{'EXIT',<0.19627.0>,shutdown}]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,987},
{stack_size,24},
{reductions,1331}],
[]]}}
--
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] [Created] (COUCHDB-1401) Add ability to configure (HTTP) log format (mod_log_config)
Add ability to configure (HTTP) log format (mod_log_config) --- Key: COUCHDB-1401 URL: https://issues.apache.org/jira/browse/COUCHDB-1401 Project: CouchDB Issue Type: Improvement Reporter: Timo Kissing I am sure there are many use cases, but in the one I am facing CouchDB is running behind a reverse proxy which means a lot of useful information is in prefixed, non-standard headers that are currently not logged. Would be great to have an equivalent to http://httpd.apache.org/docs/2.0/mod/mod_log_config.html in CouchDB -- 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] [Created] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
Critical crash of Futon after misconfigured bind_address Key: COUCHDB-1400 URL: https://issues.apache.org/jira/browse/COUCHDB-1400 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11.2 Environment: CentOS 5.5 (64-bit) Reporter: Tim Fix For: 0.11.2 I made a mistake to change the configuration table's httpd/bind_address parameter to my domain, the domain that looks like www.google.com etc. That was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this mistake long time ago but now basically I can't access anything from either localhost and external. I am unable to reverse my setting because working with /etc/couchdb/default.ini or local.ini never affected this in the first place (spent 2 hours trying to modify these fails in order to get external access of couchDB). So Futon must have changed something when I set it. When I change the value, it stuck at the error: Some of the changes require database restart. Since then, I can never access my couchDB. I tried to yum remove erlang, yum remove couchdb several times. Checked to see if any default.ini or local.ini remains, restart system, log out users, but none of above works. Please help me with this problem as soon as possible. -- 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] [Created] (COUCHDB-1399) Rename _rev to _mvcc or _lock
Rename _rev to _mvcc or _lock - Key: COUCHDB-1399 URL: https://issues.apache.org/jira/browse/COUCHDB-1399 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 2.0 Reporter: Paul Joseph Davis Fix For: 2.0 We should rename the "revisions" to "lock" or "token" or some other suitably opaque term so we stop getting people asking questions about treating them as revisions. -- 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] [Created] (COUCHDB-1398) improve view filtering in changes
improve view filtering in changes
-
Key: COUCHDB-1398
URL: https://issues.apache.org/jira/browse/COUCHDB-1398
Project: CouchDB
Issue Type: Improvement
Components: View Server Support
Affects Versions: 2.0, 1.3
Reporter: Benoit Chesneau
Improve the native view filter `_view` support by really using view index. This
patches add following features
- small refactoring: create the couch_httpd_changes modules, to put all the
changes http support in its own module instead having it in couch_httpd_db.
- add the `view_updated` event when a view index is updated : {view_updated,
{DbName, IndexName}}
- start the feed using results in the view index instead of all the db index
- only react on view index changes.
For now next changes are still get using the couch_db:changes_since function
and passing the map function to the results. It could be improved if we had a
by_seq btree in the view index too. Other way may be to skip a number of the
documents already processed. Not sure it would be faster. Thoughts ?
The branch couch_view_changes in my repo contains preliminary support:
https://github.com/benoitc/couchdb/tree/couch_view_changes
Diff:
https://github.com/benoitc/couchdb/compare/master...couch_view_changes
To use it, use the native filter named _view which take the parameter
view=DesignName/Viewname
eg:
http://server/db/_changes?feed=continuous&heartbeat=true&filter=_view&view=DesignName/SomeView
It has also an interresting side effect: on each db updates the view index
refresh is triggered so view updates are triggered. Maybe we could introduce an
optionnal parameter to not trigger them though?
--
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] [Created] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.") -- 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] [Created] (COUCHDB-1396) Deleting a conflict revision will return a wrong current doc revision
Deleting a conflict revision will return a wrong current doc revision
-
Key: COUCHDB-1396
URL: https://issues.apache.org/jira/browse/COUCHDB-1396
Project: CouchDB
Issue Type: Bug
Components: Replication
Reporter: Oliver Kurowski
Priority: Minor
After deleting the current revision to make the conflict revision the winning
one,
the returned revisionnummer ("2-f4a2a6b0c7742a5e6dd7eea7a4b625a1") is not the
revision number of the documen (1-45c1922c1b51dc5ee945218d63ce2ab4)
echo $COUCH curly -X
DELETE $COUCH/db1 curly -X
DELETE $COUCH/db2 curly -X
PUT $COUCH/db1
curly -X PUT $COUCH/db2
curly -X PUT $COUCH/db1/doc -d '{"wert":1}'
curly -X PUT $COUCH/db2/doc -d '{"wert":2}'
curly -X POST $COUCH/_replicate -d '{"source":"db1","target":"db2"}'
curly $COUCH/db2/doc\?conflicts=true
curly $COUCH/db2/doc\?revs=true
curly -X DELETE $COUCH/db2/doc\?rev=1-97cea70a7b8b41aae9e5732f4ac7
curly $COUCH/db2/doc\?conflicts=true
curly $COUCH/db2/doc\?revs=true curly $COUCH/db2/doc
sendai ~ % echo $COUCH http://localhost:5984
sendai ~ % curly -X DELETE $COUCH/db1
{"ok" : true }
sendai ~ % curly -X DELETE $COUCH/db2
{"ok" : true }
sendai ~ % curly -X PUT $COUCH/db1
{"ok" : true }
sendai ~ % curly -X PUT $COUCH/db2
{"ok" : true }
sendai ~ % curly -X PUT $COUCH/db1/doc -d '{"wert":1}'
{"ok" : true,"rev" : "1-97cea70a7b8b41aae9e5732f4ac7","id" :
"doc" }
sendai ~ % curly -X PUT $COUCH/db2/doc -d '{"wert":2}'
{"ok" : true,"rev" : "1-45c1922c1b51dc5ee945218d63ce2ab4","id" :
"doc" }
sendai ~ % curly -X POST $COUCH/_replicate -d '{"source":"db1","target":"db2"}'
{"ok" : true,"history" : [ { "docs_read" : 1,
"session_id" : "7c74c9bb9f322e10ad072215e823c2d8", "recorded_seq" : 1,
"end_last_seq" : 1, "doc_write_failures" : 0,
"start_time" : "Mon, 30 Jan 2012 20:34:18 GMT", "start_last_seq" : 0,
"end_time" : "Mon, 30 Jan 2012 20:34:18 GMT",
"missing_checked" : 0, "docs_written" : 1, "missing_found" :
1 }],"session_id" : "7c74c9bb9f322e10ad072215e823c2d8",
"source_last_seq" : 1,"replication_id_version" : 2 }
sendai ~ % curly $COUCH/db2/doc\?conflicts=true
{"_id" : "doc","wert" : 1,"_conflicts" : [
"1-45c1922c1b51dc5ee945218d63ce2ab4"],"_rev" :
"1-97cea70a7b8b41aae9e5732f4ac7" }
sendai ~ % curly $COUCH/db2/doc\?revs=true
{"_id" : "doc","wert" : 1,"_revisions" : { "ids" : [
"97cea70a7b8b41aae9e5732f4ac7" ], "start" : 1},"_rev" :
"1-97cea70a7b8b41aae9e5732f4ac7" }
sendai ~ % curly -X DELETE
$COUCH/db2/doc\?rev=1-97cea70a7b8b41aae9e5732f4ac7
{"ok" : true,"rev" : "2-f4a2a6b0c7742a5e6dd7eea7a4b625a1","id" :
"doc" }
sendai ~ % curly $COUCH/db2/doc\?conflicts=true {"_id" : "doc","wert" :
2,"_rev" : "1-45c1922c1b51dc5ee945218d63ce2ab4" }
sendai ~ % curly $COUCH/db2/doc\?revs=true {"_id" : "doc","wert" : 2,
"_revisions" : { "ids" : [ "45c1922c1b51dc5ee945218d63ce2ab4"
], "start" : 1},"_rev" : "1-45c1922c1b51dc5ee945218d63ce2ab4"
}
sendai ~ % curly $COUCH/db2/doc {"_id" : "doc","wert" : 2,"_rev" :
"1-45c1922c1b51dc5ee945218d63ce2ab4" }
sendai ~ %
--
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] [Created] (COUCHDB-1395) Not well-formed JSON in changes feed filtered by view.
Not well-formed JSON in changes feed filtered by view.
--
Key: COUCHDB-1395
URL: https://issues.apache.org/jira/browse/COUCHDB-1395
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-d59cdd7-git
Apache CouchDB 1.2.0a-0d8ddc8-git
Reporter: Alexander Shorin
Priority: Critical
CouchDB returns invalid JSON response for _changes feed if filter view have
failed somehow: by code mistake, bug, os timeout etc.
Steps to reproduce:
1. Create db and fill it with some documents.
2. Create buggy view that would make view server crush for some document. For
javascript one segfault and os timeout errors are actual due to any exceptions
raised from map function is silenced. You view could be fine however for
normal usage.
3. Request changes feed and apply this buggy view as filter.
Story:
View function had never proceed design documents and mostly they are created
with that knowledge. But in changes feed they have to process every document in
database and DDocs too, so they breaks their original logic and creates
unexpectable situation. Another side of problem is about custom query servers
that could prevent view processing on first occurred exception or due dynamic
code execution nature.
Certainly, it's all about invalid view function that generates exception for
some document in some case, but should _changes feed return malformed data in
this case or just notify about problem somehow and emit valid parseable JSON?
Expected result:
Valid JSON response and some message about document processing error.
Actual result:
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /filtered_view_bug/_changes?filter=_view&view=bug/crush_on_ddoc HTTP/1.1
> User-Agent: curl/7.21.4 (x86_64-pc-linux-gnu) libcurl/7.21.4 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: application/json
>
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Server: CouchDB/1.3.0a-d59cdd7-git (Erlang OTP/R14B04)
< ETag: "3IV66Q7INUYEHYKVWADD0CA8A"
< Date: Thu, 26 Jan 2012 19:30:23 GMT
< Content-Type: application/json
< Cache-Control: must-revalidate
<
{"results":[
{"seq":1,"id":"foo","changes":[{"rev":"1-5277061607e266deb7cc87eb63354db7"}]},
{"seq":2,"id":"bar","changes":[{"rev":"1-ced1ed0168f00311e1ee301cda904840"}]},
{"seq":3,"id":"baz","changes":[{"rev":"1-ae16db0d925a8295009ff580e226a978"}]}
* Received problem 2 in the chunky parser
* Closing connection #0
curl: (56) Received problem 2 in the chunky parser
Last chunk arrives with "HTTP/1.1 500 Internal Server Error" instead of size
value.
--
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] [Created] (COUCHDB-1394) Compaction doesn't allow to change database compression for version 6 databases
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 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] [Created] (COUCHDB-1393) badmatch on big binary
badmatch on big binary
--
Key: COUCHDB-1393
URL: https://issues.apache.org/jira/browse/COUCHDB-1393
Project: CouchDB
Issue Type: Bug
Reporter: Jan Lehnardt
via dev@ by Peta Bogdan
Hello,
I have a small database around 120 MB with approximately 16,000 documents.
However, it happens (also from futon) that I get this error:
[Tue, 17 Jan 2012 07:22:01 GMT] [error] [<0.185.0>] {error_report,<0.30.0>,
{<0.185.0>,crash_report,
[[{initial_call,{couch_file,init,['Argument__1']}},
{pid,<0.185.0>},
{registered_name,[]},
{error_info,
{exit,
{{badmatch,
{ok,
9_MEGABYTES_BINARY}},
[{couch_file,read_raw_iolist_int,3},
{couch_file,maybe_read_more_iolist,4},
{couch_file,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]},
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,[<0.184.0>]},
{messages,
[{'$gen_call',
{<0.10840.18>,#Ref<0.0.3.20907>},
bytes}]},
{links,[<0.190.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,1597},
{stack_size,24},
{reductions,65666}],
[{neighbour,
[{pid,<0.190.0>},
{registered_name,[]},
{initial_call,
{couch_ref_counter,init,['Argument__1']}},
{current_function,{gen_server,loop,6}},
{ancestors,[<0.188.0>,<0.187.0>,<0.184.0>]},
{messages,[]},
{links,[<0.185.0>]},
{dictionary,[]},
{trap_exit,false},
{status,waiting},
{heap_size,610},
{stack_size,9},
{reductions,362}]}]]}}
If this error occurs to frequently causes couch_server to reach its max
restart frequency causing the entire supervision tree to shutdown and hence
the database server instance disappears.
The function couch_file:read_raw_iolist_int/3 calls file:pread which
returns {ok, Binary}. This Binary has almost 9 megabytes in size, which is
very strange.
I think this does mean that the function file:pread/3 is instructed to read
from wrong position.
The only reason I can think of is that the value of 'TotalBytes' from line
(1) doesn't match the value of 'TotalBytes' from line (2)
(1) TotalBytes = calculate_total_read_len(BlockOffset, Len),
(2) {ok, <>} = file:pread(Fd, Pos, TotalBytes),
The possible answer would be that in certain conditions the function
calculate_total_read_len/2 doesn't return the expected value.
Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
OS: OpenBSD 5.0 GENERIC.MP#63 amd64
Now, the trouble is how to circumvent this situation.
Thank you in advance,
Bogdan
--
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] [Created] (COUCHDB-1392) Increase task status update frequency for continuous replication
Increase task status update frequency for continuous replication Key: COUCHDB-1392 URL: https://issues.apache.org/jira/browse/COUCHDB-1392 Project: CouchDB Issue Type: Improvement Reporter: Paul Joseph Davis Assignee: Filipe Manana I'm not super familiar with the internals of continuous replication but the tests would benefit from a slight tweak to increasing the frequency of task status updates. I'm not entirely certain on the internals, but assuming that its something like "wait for update notifications, scan by_seq_btree for new updates, sleep" it would be useful to update the task status unconditionally at the end of "scan by_seq_tree". This would benefit the continuous replication tests because we'd be able to fix the waitForSeq so that as soon as the target db was up to date the tests could continue instead of the broken behavior where they wait for the entire timeout now. -- 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] [Created] (COUCHDB-1391) Implement _security as _local doc with revision trees
Implement _security as _local doc with revision trees
-
Key: COUCHDB-1391
URL: https://issues.apache.org/jira/browse/COUCHDB-1391
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Reporter: Paul Joseph Davis
We had a discussion [1] a while back about updating the _security object so
that it could be replicated (internally) in a cluster or similar environment.
The basic gist was "update _local docs to have a revision tree, update
_security to be a _local doc with docid "_local/_security" and keep the current
_security API for a version or two for backwards compatibility (or forever,
what color is your bike shed?)"
So I did that.
Basic patch progression is:
1. Refactor revision merging logic so that we can split it out of
couch_db_updater's code path for updating normal docs.
2. Implement _local docs with #full_doc_info{} records (and thus revision trees)
3. Implement _security as _local/_security
These things are done. Tests should theoretically pass after each patch but I
haven't gone back and tried. They definitely pass (minus auth_cache which I
just submitted a fix for) now except for replication.js appears to fail for
random reasons. I can't quite decide if I've introduced this or if it just
fails randomly. Rather than run it a lot more times and continue to be confused
I'm starting this ticket so I can have other people test and tell me their
results.
Also, the test suite is rather wonky on trunk with segfaults. We should really
look into that more.
Patches forth coming. I've also pushed the branch to [2].
[1]
http://grokbase.com/t/couchdb.apache.org/dev/2011/08/the-security-object-should-be-versioned/17rfmmtlu3lagqvgyq7cay26dqk4
[2]
http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=refs/heads/new-security-object
--
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] [Created] (COUCHDB-1390) Fix auth_cache etap test
Fix auth_cache etap test Key: COUCHDB-1390 URL: https://issues.apache.org/jira/browse/COUCHDB-1390 Project: CouchDB Issue Type: Bug Reporter: Paul Joseph Davis Attachments: COUCHDB-1390.patch The auth_cache etap tests were failing for me. Debugged this to make sure it wasn't related to something else. Commit message is: Fix for the auth_cache etap As it turns out, opening a doc by id is different than opening it using a #doc_info record due to the inclusion of the full revision path. This ended up breaking the auth_cache tests. This way includes the entire revision path for all docs and not just first doc loads. Patching attaching in a few moments. -- 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] [Created] (COUCHDB-1389) Improve JS CLI test error reports
Improve JS CLI test error reports - Key: COUCHDB-1389 URL: https://issues.apache.org/jira/browse/COUCHDB-1389 Project: CouchDB Issue Type: Improvement Reporter: Paul Joseph Davis Attachments: COUCHDB-1389.patch About to attach a simple patch that gives better error output when JS tests fail. -- 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] [Created] (COUCHDB-1388) Support Windows Phone 7
Support Windows Phone 7 --- Key: COUCHDB-1388 URL: https://issues.apache.org/jira/browse/COUCHDB-1388 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.1.2 Environment: Windows Phone 7 Reporter: Chang Luo Fix For: 1.1.2 Now that we have support for iOS and Android, I am looking forward to Windows Phone 7. -- 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] [Created] (COUCHDB-1387) couch_index_server:reset_indexes/2 does not use the correct utility function
couch_index_server:reset_indexes/2 does not use the correct utility function
Key: COUCHDB-1387
URL: https://issues.apache.org/jira/browse/COUCHDB-1387
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.3
Reporter: Jason Smith
Priority: Trivial
Attachments:
0001-Use-the-correct-utility-function-to-get-the-index-di.patch
It looks like couch_index_util:index_dir(Module, DbName) is the new way to get
the path to the .db_design/ directory.
Passing an empty string as the "module" gives the desired result. So why not
use that?
1> couch_index_util:index_dir("", <<"mydb">>).
"/Users/jhs/src/iris/couchdb/tmp/lib/.mydb_design"
--
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] [Created] (COUCHDB-1386) investigate adding js-config support when appropriate
investigate adding js-config support when appropriate - Key: COUCHDB-1386 URL: https://issues.apache.org/jira/browse/COUCHDB-1386 Project: CouchDB Issue Type: Improvement Reporter: Randall Leeds Assignee: Randall Leeds Priority: Minor js-config is a script that can be output from a SpiderMonkey build, but currently we don't check for it. It's often not available, as per the note at [1], but would be the preferred solution to finding the correct JS library. I think the current build system might conflate the libmozjs185 name with some feature detection in a way that's not forward-friendly, i.e. if the library is just libmozjs then it's "old" and that's not going to be the case forever (I hope). [1] https://developer.mozilla.org/en/SpiderMonkey/1.8.5#js-config -- 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] [Created] (COUCHDB-1385) Build should force use of help2man for distribution
Build should force use of help2man for distribution --- Key: COUCHDB-1385 URL: https://issues.apache.org/jira/browse/COUCHDB-1385 Project: CouchDB Issue Type: Bug Components: Build System Reporter: Noah Slater Priority: Minor At the moment, the presence of, and hence use of, help2man is entirely optional. This is fine for users who are building from source. But when preparing the source for release, help2man should be mandated. CouchDB source archives should ship with man pages pre-generated. -- 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] [Created] (COUCHDB-1384) File descriptor leak if view compaction is cancelled
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] [Created] (COUCHDB-1383) Futon view editor won't allow you to save original view (reverting) after saving a revision
Futon view editor won't allow you to save original view (reverting) after saving a revision --- Key: COUCHDB-1383 URL: https://issues.apache.org/jira/browse/COUCHDB-1383 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.1, 1.2 Reporter: Sam Bisbee Priority: Minor Steps to reproduce: 1. Load a view that was already created. 2. Change the view in some way (add space or whatever). 3. Click Save. 4. Revert your change (remove the space or whatever). Expected Result: You should be able to click Save, thereby essentially reverting back to the original view code. Actual Result: You cannot click Save - the button is still disabled. -- 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] [Created] (COUCHDB-1382) Use term_to_binary with minor_version=1 to reduce disk size of data and indexes
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 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] [Created] (COUCHDB-1381) Support Windows 8 Metro Apps
Support Windows 8 Metro Apps
Key: COUCHDB-1381
URL: https://issues.apache.org/jira/browse/COUCHDB-1381
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Affects Versions: 1.1.1
Environment: Windows 8
Reporter: Chang Luo
Priority: Critical
Fix For: 1.1.2
jquery.couch.js doesn't work for Windows 8 Metro apps. Below code works fine
on browsers. However when run within a Windows 8 Metro app, it throws an error
in line 665 jquery.couch.js: alert undefined.
If this is hard to fixed, any alternative javascript library recommendation is
welcome.
CouchDB jQuery Examples
console.log('starting');
$.couch.urlPrefix = "http://localhost:5984";;
$.couch.db("_users").allDocs({
success: function (data) {
console.log();
}
});
console.log('done');
--
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] [Created] (COUCHDB-1380) logrotate doesn't work correctly with couchdb 1.2.x
logrotate doesn't work correctly with couchdb 1.2.x
---
Key: COUCHDB-1380
URL: https://issues.apache.org/jira/browse/COUCHDB-1380
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2
Environment: CentOS 5.6 x64, couchdb 1.2.x (13th Jan 2012 -
1.2.0a-08d8f89-git), logrotate 3.7.4
Reporter: Alex Markham
Priority: Minor
Running logrotate -f with couchdb 1.2.x leaves null data at the start of the
couch.log file, I'm guessing equal to the size of data that should have been
removed and rotated into the log.1 (eg "head -c 10 couch.log" is blank)
This does not happen on couchdb 1.1.1, 1.0.2 or 1.0.3
The log files then stay large, and when trying to grep or less them, they are
reported as binary.
This seems to have happened to another user, but no details of OS or version
were reported: http://comments.gmane.org/gmane.comp.db.couchdb.user/16049
The logrotate config used is very similar to the one installed with couchdb -
/var/log/couchdb/*.log {
size=150M
rotate 5
copytruncate
compress
delaycompress
notifempty
missingok
}
Has there been any changes to the interaction with log files/file handles since
1.1.1? Does couchdb need to receive a SIGHUP? Or can anyone reproduce this?
--
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] [Created] (COUCHDB-1379) Extend attachment etag checking for compressible data types in test suite
Extend attachment etag checking for compressible data types in test suite -- Key: COUCHDB-1379 URL: https://issues.apache.org/jira/browse/COUCHDB-1379 Project: CouchDB Issue Type: Test Components: Database Core Affects Versions: 1.2 Reporter: Dave Cottlehuber Assignee: Dave Cottlehuber Priority: Trivial Fix For: 1.2.1 Ref COUCHDB-1337 and subsequent 8d83b3 on 1.2.0/12.x branch. etag testing was extended to validate the digest returned by CouchDB for attachments. Compressed attachments do not produce a consistent digest across platforms, due to differing compression algorithms between Mac/Linux and Windows. The test suite should confirm that etags only change when the attachment is updated, and are otherwise consistent. -- 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] [Created] (COUCHDB-1378) Installing on OSX wiki page incorrect
Installing on OSX wiki page incorrect - Key: COUCHDB-1378 URL: https://issues.apache.org/jira/browse/COUCHDB-1378 Project: CouchDB Issue Type: Bug Reporter: Jason Sachs Priority: Minor http://wiki.apache.org/couchdb/Installing_on_OSX lists two sources for OSX binaries; neither are valid anymore (2nd one doesn't exist, 1st one just points to Couchbase Single Server, which does have binaries for OSX but they don't work and Couchbase isn't supporting Single Server anymore.) -- 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] [Created] (COUCHDB-1377) support X-Forwarded-* headers in couch_httpd
support X-Forwarded-* headers in couch_httpd Key: COUCHDB-1377 URL: https://issues.apache.org/jira/browse/COUCHDB-1377 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.1.1, 1.2 Reporter: Randall Leeds Assignee: Randall Leeds Fix For: 1.2.1, 1.3 X-Forwarded-For, as well as X-Forwarded-Proto and X-Forwarded-Ssl, are partially supported by the couch_httpd module. However, the couch_httpd_proxy module ignores these same configuration settings when it could manipulate the headers to pass more information upstream. -- 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] [Created] (COUCHDB-1376) enable JaegerMonkey features
enable JaegerMonkey features Key: COUCHDB-1376 URL: https://issues.apache.org/jira/browse/COUCHDB-1376 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Randall Leeds Assignee: Randall Leeds Priority: Minor Fix For: 1.3 In recent versions of SpiderMonkey, the method JIT (sometimes referred to as JaegerMonkey) is considered stable for use and ships on by default in Firefox builds. Newer, unreleased, upstream versions also have type inference. -- 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] [Created] (COUCHDB-1375) couch_query_servers pool deadlock when running "os_process_limit" indexers
couch_query_servers pool deadlock when running "os_process_limit" indexers -- Key: COUCHDB-1375 URL: https://issues.apache.org/jira/browse/COUCHDB-1375 Project: CouchDB Issue Type: Bug Components: View Server Support Affects Versions: 1.1 Reporter: Filipe Manana When using external view servers, such as couchjs for example, if we trigger "os_process_limit" (or more) index updates simultaneously, we can reach a deadlock case. The issue is that each index updater will acquire a couchjs (os_proc record) process from couch_query_servers to apply the map function against each document. After the indexer finishes, it will release (return to couch_query_servers) the couchjs process used for the maps. However, while the indexer is writing to the btrees, if the reduce function is a JavaScript function (or any other language other than Erlang or a builtin reduce function), the function is called often to reduce key-values - this results in the view updater process to ask couch_query_servers for a another couchjs process (this is done on every reduce function call) - however "os_process_limit" couchjs processes are already allocated to "os_process_limit" indexers for the mapping. The solution here would be to have the index updater to preallocate a couchjs process for the reduces and release it when it finishes (like it's done for the maps). This only happens if the number of changes to index is greater than 500 (the work queue sizes). -- 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] [Created] (COUCHDB-1374) Admin users never get deleted
Admin users never get deleted
-
Key: COUCHDB-1374
URL: https://issues.apache.org/jira/browse/COUCHDB-1374
Project: CouchDB
Issue Type: Bug
Components: Build System
Affects Versions: 1.1.1
Reporter: Marcos Zanona
Fix For: 1.2, 1.3, 1.1.2
It seems that when creating an admin user and then deleting that same user with
another admin makes the first user stay active, resulting in a no deletion and
doesn't block the access to the old user access.
It becomes marked as {"error":"not_found","reason":"deleted"} but still having
access to the whole system as an admin.
--
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] [Created] (COUCHDB-1373) Time-ordered document ids including the database identity
Time-ordered document ids including the database identity -- Key: COUCHDB-1373 URL: https://issues.apache.org/jira/browse/COUCHDB-1373 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Nick North Priority: Minor This suggestion is for an enhancement to the document id generation algorithms in CouchDb. I am new to CouchDb, and this question addresses an old issue (https://issues.apache.org/jira/browse/COUCHDB-465) so please forgive me if I am retreading old ground. My application has a number of mutually replicating CouchDb instances and I would like document ids to be monotonically-increasing per-instance, and globally unique, and for the instance where the document was created to be determinable from the id. (To be more accurate - I don't need to know anything about the instance itself; just whether any two documents originated from the same instance.) The utc_random algorithm is not far from meeting these requirements, as ids are monotonic and almost certainly globally unique. However, the instance cannot be determined from the id, and there is a tiny chance of an id clash between two instances. Both of these issues could be solved if the random part of the id could be replaced with a suffix that is fixed in the ini file for each instance. To addresses this I have a modified version of couch_uuids.erl introducing a new utc_machine_id algorithm which reads a machine_id string from the ini file and then generates ids using an internal utc_suffix method that just appends the string to the usual utc 14-byte string. utc_random then also uses the utc_suffix method, but its suffix is the usual random byte string. However, it is obviously a nuisance to have to maintain a non-standard distribution, so I wondered if there is enough call for this sort of thing to make it a part of the standard distribution? If there is, I'd be very happy to make my code available for discussion/modification/inclusion. If there are good reasons why this is a bad idea, then I'd also be very interested to hear them so that I can rethink my ideas. (It happens that the privacy and guessability concerns raised in the original discussion do not apply in my case.) If this question has been beaten to death, then I'm sorry for bothering the group, and would be grateful if someone could point me to the discussions so that I can understand the issues. -- 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] [Created] (COUCHDB-1372) "_stats" reduce producing errors on empty views
"_stats" reduce producing errors on empty views --- Key: COUCHDB-1372 URL: https://issues.apache.org/jira/browse/COUCHDB-1372 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.1.1 Environment: windows, most likely effects all systems Reporter: paul iannazzo have a database with any number of documents in it. create a map that outputs 0 things (no emits called). use reduce : "_stats". an error should occur. it's very common to have views be an empty set since maps act as filters in couchdb. when i use my own reduce functions i don't get errors, only with the standard couchdb functions. this wouldn't be a problem if i could use commonJS in my reduces. -- 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] [Created] (COUCHDB-1371) configure erroneously warns against using a new spidermonkey with old spidermonkeys
configure erroneously warns against using a new spidermonkey with old spidermonkeys --- Key: COUCHDB-1371 URL: https://issues.apache.org/jira/browse/COUCHDB-1371 Project: CouchDB Issue Type: Bug Reporter: Randall Leeds Assignee: Randall Leeds Priority: Minor Fix For: 1.2, 1.3, 1.1.2 Attachments: 0001-fix-bad-configure-warning-on-old-SpiderMonkey.patch Paul added the check for JSOPTION_ANONFUNFIX in 7ce9e103e, but js-1.7 doesn't have this constant so configure gives a warning. -- 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] [Created] (COUCHDB-1370) Content-Length in Quick Start Create View example is 79, should be 76
Content-Length in Quick Start Create View example is 79, should be 76
-
Key: COUCHDB-1370
URL: https://issues.apache.org/jira/browse/COUCHDB-1370
Project: CouchDB
Issue Type: Bug
Components: Documentation
Reporter: James Tikalsky
Priority: Minor
Title: Couch DB Quick Start
URL: http://wiki.apache.org/couchdb/CouchIn15Minutes
Description:
Using the documented Create View causes the database connection to timeout and
close without creating the view.
Expected Example Text:
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
PUT /example/_design/render HTTP/1.0
Content-Length: 76
Content-Type: application/json
{"shows" : {"salute" : "function(doc, req) {return {body: doc.greetings}}"}}
Actual Example Text:
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
PUT /example/_design/render HTTP/1.0
Content-Length: 79
Content-Type: application/json
{"shows" : {"salute" : "function(doc, req) {return {body: doc.greetings}}"}}
--
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] [Created] (COUCHDB-1369) https config change
https config change
---
Key: COUCHDB-1369
URL: https://issues.apache.org/jira/browse/COUCHDB-1369
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Benoit Chesneau
Priority: Blocker
Changing configuration of the ssl port make the server crashing. COnfiguration
isn't saved and https isn't available anymore.
Step to reproduce:
1. Enable ssl by uncommenting httpsd daemon line in local.ini and set key_file
& cert_file in ssl section
2. start couchdb
3. Change port using the `_config` interface:
curl -XPUT 'http://127.0.0.1:5984/_config/ssl/port' -d'"6987"'
"6986"
log:
[error] [<0.95.0>] {error_report,<0.30.0>,
{<0.95.0>,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,child_terminated},
{reason,normal},
{offender,
[{pid,<0.172.0>},
{name,httpd},
{mfargs,{couch_httpd,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
=SUPERVISOR REPORT 24-Dec-2011::11:54:36 ===
Supervisor: {local,couch_secondary_services}
Context:child_terminated
Reason: normal
Offender: [{pid,<0.172.0>},
{name,httpd},
{mfargs,{couch_httpd,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]
The server restart but change isn't took in consideration.
--
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
