Re: stray couchjs processes
Hi Ning, the correlation between couchjs and HTTP requests is that whenever a request needs couchjs for anything, it will use one that is around and idle. When CouchDB starts, none are idle and it will for and exec a new couchjs process. A couchjs process is not idle when a request is using it. So for every concurrent request, you will get a new fork exec of a couchjs process. I haven't looked at the current implementation in a while, but we should look into implementing some configurable ceiling that can't be crossed with more fork exec. Requests then could either wait until a couchjs is idle and eventually timeout if none get freed or they could get served a Service Unavailable (503) — That behaviour should also be configurable. CCing dev@ to see if we can get more feedback on this. Cheers Jan -- On 15 Apr 2011, at 20:16, Ning Tan wrote: A while back there was a post about stray couchjs processes that had no apparent resolution. A similar situation happened in our environment that resulted in hundreds of couchjs processes, which caused out-of-memory problems for the server. We are investigating the cause and would appreciate any help in pinpointing the problem. One thing that was curious to me is, how many couchjs processes are needed to support concurrent requests. I couldn't reproduce a large number of couchjs processes in my local environment. It seems that all my view/filter requests were handled by just one couchjs process. The environment that had problems was using 1.0.1. I've been testing locally with 1.0.2. Would that make any difference? Also, the problematic environment had proxies sitting in front of the couch boxes, so that's another variance in our analysis. But it's hard to tell without knowing the relationship/cardinality between an HTTP connection and a couchjs process. In the original post, connections not properly closed were hinted as a potential culprit. However, it's still unclear to me how mishandled HTTP connections can result in multiple couchjs processes. If I'm not mistaken, couchjs only talks via stdin/stdout and is not handling a connection directly. Sorry if this question doesn't have enough information. We are still in very early stages of our analysis and don't have a lot of leads yet. Thanks!
Re: stray couchjs processes
I've seen this bug in the wild. I haven't been able to track down the exact root cause, but the various ets tables in couch_query_servers get out of sync with one another - one table will think there are no available processes and will cause new ones to be spawned but the others will still have some record of the hundreds of spawned couchjs processes. I rewrote the gen_server to use a single ets table and refactored a few other things in COUCHDB-901[1]. It's missing a hard limit on the number of processes that we'll spawn, and instead has a soft limit above which it will discard processes after their workload has finished. I'm overdue to finish that ticket off and get it into trunk. Regards, Adam [1]: https://issues.apache.org/jira/browse/COUCHDB-901 On Apr 16, 2011, at 8:39 AM, Jan Lehnardt wrote: Hi Ning, the correlation between couchjs and HTTP requests is that whenever a request needs couchjs for anything, it will use one that is around and idle. When CouchDB starts, none are idle and it will for and exec a new couchjs process. A couchjs process is not idle when a request is using it. So for every concurrent request, you will get a new fork exec of a couchjs process. I haven't looked at the current implementation in a while, but we should look into implementing some configurable ceiling that can't be crossed with more fork exec. Requests then could either wait until a couchjs is idle and eventually timeout if none get freed or they could get served a Service Unavailable (503) — That behaviour should also be configurable. CCing dev@ to see if we can get more feedback on this. Cheers Jan -- On 15 Apr 2011, at 20:16, Ning Tan wrote: A while back there was a post about stray couchjs processes that had no apparent resolution. A similar situation happened in our environment that resulted in hundreds of couchjs processes, which caused out-of-memory problems for the server. We are investigating the cause and would appreciate any help in pinpointing the problem. One thing that was curious to me is, how many couchjs processes are needed to support concurrent requests. I couldn't reproduce a large number of couchjs processes in my local environment. It seems that all my view/filter requests were handled by just one couchjs process. The environment that had problems was using 1.0.1. I've been testing locally with 1.0.2. Would that make any difference? Also, the problematic environment had proxies sitting in front of the couch boxes, so that's another variance in our analysis. But it's hard to tell without knowing the relationship/cardinality between an HTTP connection and a couchjs process. In the original post, connections not properly closed were hinted as a potential culprit. However, it's still unclear to me how mishandled HTTP connections can result in multiple couchjs processes. If I'm not mistaken, couchjs only talks via stdin/stdout and is not handling a connection directly. Sorry if this question doesn't have enough information. We are still in very early stages of our analysis and don't have a lot of leads yet. Thanks!
Re: Couchdb trunk purge_docs timeout
Hi Mike,
we did a fix in this area recently that affected purging of docs in conflict:
http://svn.apache.org/viewvc?rev=1086241view=rev
A couple of reviewers deemed the patch safe, but this is a seldom exercised
part of the code, so we may have introduced your issue.
Can you provide us with a reproducing script that maybe doesn't depend on
56m docs? :)
Also, can you paste the full error stack trace?
A few more questions:
- Is replication involved here?
- Do you have more I/O than before on the system?
CCing dev@.
Cheers
Jan
--
On 14 Apr 2011, at 17:14, Mike Leddy wrote:
Hi,
I have a couch node current using version 1.2.0abaa0e30-git. I decided
to try a database maintenance task that I formerly used to use on
couchdb 1.0.2 to purge documents in batches of 500 on a database that
contains some 56 million documents.
From what I can gather from the logs the call to purge_docs is timing
out after 5 seconds and terminating.
[Wed, 13 Apr 2011 20:25:57 GMT] [info] [0.5192.19] 172.17.17.3 - - GET
/iris/_design/tidy/_view/conflicts?limit=0 200
[Wed, 13 Apr 2011 20:26:02 GMT] [error] [0.5194.19] Uncaught error in HTTP
request: {exit,
{timeout,
{gen_server,call,
[0.150.0,
{purge_docs,
[{1294099271F6261,
[{1,
181,64,95,
54,247,104,
56,34,109,
228,7,108,
250,72,57,
190}]},
{1294099281F7327,
[{1,
80,246,15,
155,182,61,
43,238,207,
43,159,136,
178,134,
137,214}]},
... removed for brevity
[Wed, 13 Apr 2011 20:26:02 GMT] [info] [0.5194.19] Stacktrace:
[{io_lib_pretty,cind_tag_tuple,7},
{io_lib_pretty,while_fail,3},
{io_lib_pretty,print,6},
{io_lib_format,build,3},
{io_lib_format,build,3},
{io_lib_format,build,3},
{io_lib_format,build,3},
{io_lib_format,build,3}]
[Wed, 13 Apr 2011 20:26:02 GMT] [info] [0.5194.19] 172.17.17.3 - - POST
/iris/_purge 500
I am pretty sure that this was not the case with 1.0.2. Does anyone
have any insight regarding what is the root cause of the problem ?
Meanwhile I'm digging through the code looking for clues
Thanks,
Mike
[jira] [Resolved] (COUCHDB-951) Test DB upgrade for 1.0.x to 1.1.0
[ https://issues.apache.org/jira/browse/COUCHDB-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson resolved COUCHDB-951. --- Resolution: Fixed Plenty of successful verification runs reported and no reliably reproducible failures. Job done. Test DB upgrade for 1.0.x to 1.1.0 -- Key: COUCHDB-951 URL: https://issues.apache.org/jira/browse/COUCHDB-951 Project: CouchDB Issue Type: Test Affects Versions: 1.1 Reporter: Robert Newson Assignee: Robert Newson Fix For: 1.1 As the on-disk format has changed (for Range header support for attachments) extensive testing of db upgrades should be performed. The Range upgrade occurs on compaction, so it should suffice to; 1) create a db with 1.0.x 2) upgrade to 1.1.0 3) compact 4) verify db I will be working on scripts to automate as much as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: stray couchjs processes
Hah, thanks Adam, this is exactly the email I hoped to see by CCing dev@ :) Cheers Jan -- On 16 Apr 2011, at 15:09, Adam Kocoloski wrote: I've seen this bug in the wild. I haven't been able to track down the exact root cause, but the various ets tables in couch_query_servers get out of sync with one another - one table will think there are no available processes and will cause new ones to be spawned but the others will still have some record of the hundreds of spawned couchjs processes. I rewrote the gen_server to use a single ets table and refactored a few other things in COUCHDB-901[1]. It's missing a hard limit on the number of processes that we'll spawn, and instead has a soft limit above which it will discard processes after their workload has finished. I'm overdue to finish that ticket off and get it into trunk. Regards, Adam [1]: https://issues.apache.org/jira/browse/COUCHDB-901 On Apr 16, 2011, at 8:39 AM, Jan Lehnardt wrote: Hi Ning, the correlation between couchjs and HTTP requests is that whenever a request needs couchjs for anything, it will use one that is around and idle. When CouchDB starts, none are idle and it will for and exec a new couchjs process. A couchjs process is not idle when a request is using it. So for every concurrent request, you will get a new fork exec of a couchjs process. I haven't looked at the current implementation in a while, but we should look into implementing some configurable ceiling that can't be crossed with more fork exec. Requests then could either wait until a couchjs is idle and eventually timeout if none get freed or they could get served a Service Unavailable (503) — That behaviour should also be configurable. CCing dev@ to see if we can get more feedback on this. Cheers Jan -- On 15 Apr 2011, at 20:16, Ning Tan wrote: A while back there was a post about stray couchjs processes that had no apparent resolution. A similar situation happened in our environment that resulted in hundreds of couchjs processes, which caused out-of-memory problems for the server. We are investigating the cause and would appreciate any help in pinpointing the problem. One thing that was curious to me is, how many couchjs processes are needed to support concurrent requests. I couldn't reproduce a large number of couchjs processes in my local environment. It seems that all my view/filter requests were handled by just one couchjs process. The environment that had problems was using 1.0.1. I've been testing locally with 1.0.2. Would that make any difference? Also, the problematic environment had proxies sitting in front of the couch boxes, so that's another variance in our analysis. But it's hard to tell without knowing the relationship/cardinality between an HTTP connection and a couchjs process. In the original post, connections not properly closed were hinted as a potential culprit. However, it's still unclear to me how mishandled HTTP connections can result in multiple couchjs processes. If I'm not mistaken, couchjs only talks via stdin/stdout and is not handling a connection directly. Sorry if this question doesn't have enough information. We are still in very early stages of our analysis and don't have a lot of leads yet. Thanks!
[jira] [Updated] (COUCHDB-901) refactor os process management
[ https://issues.apache.org/jira/browse/COUCHDB-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-901: - Fix Version/s: 1.2 Raising for 1.2.0 refactor os process management -- Key: COUCHDB-901 URL: https://issues.apache.org/jira/browse/COUCHDB-901 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.0.1 Reporter: Adam Kocoloski Fix For: 1.2 Wanted to make sure this doesn't get forgotten in the planning for 1.1. Paul Davis and I independently refactored couch_query_servers. Paul's work is much more comprehensive and includes a switch to emonk: http://github.com/davisp/couchdb/tree/emonk The work I did is here http://github.com/kocolosk/couchdb/tree/COUCHDB-901 One feature not included in that branch is the ability to limit the number of OS processes. Should be simple to add if my work ends up being merged. I did the refactor because I was having problems with couch_query_servers forgetting about OS processes in BigCouch. One of the ets tables held by couch_query_servers would list thousands of processes (and in fact there were thousands of spawned couchjs), but another table would claim that only two were running. After digging through the code a while I became frustrated with all of the tracking of multiple ets tables and rewrote a server that used only one table. Other changes include * ability to reuse an OS process when the client that requested it dies. * better behavior under config changes - doesn't kill all query servers when [query_servers] or [native_query_servers] block changes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-994) Crash after compacting large views
[ https://issues.apache.org/jira/browse/COUCHDB-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-994: - Fix Version/s: 1.2 Raising for 1.2 Crash after compacting large views -- Key: COUCHDB-994 URL: https://issues.apache.org/jira/browse/COUCHDB-994 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.2 Environment: Centos5 64bit vm with 2CPU and 4G RAM running Erlang R14B and configured to use the 64bit js-devel libraries. URL: http://svn.apache.org/repos/asf/couchdb/branches/1.0.x Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1050680 Reporter: Bob Clary Fix For: 1.2 Attachments: couch_errors.txt, couch_errors_2.txt The database has over 9 million records. Several of the views are relatively dense in that they emit a key for most documents. The views are successfully created initially but with relatively large sizes from 20 to 95G. When attempting to compact them, the server will crash upon completion of the compaction. This does not occur with the released 1.0.1 version but does with the 1.0.x svn version. I'll attach example logs. Unfortunately they are level error and may not have enough information. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Futon doesn't work with Firefox 4.0b9?
Also weird was I tried opening it in a different tab and everything was fine. Perhaps Firebug being annoying? On 14 April 2011 21:47, Dale Harvey d...@arandomurl.com wrote: actually it is in trunk and 1.0.2 + 1.1 not 1.0.1 though On 14 April 2011 13:44, Dale Harvey d...@arandomurl.com wrote: weird I thought I patched this https://issues.apache.org/jira/browse/COUCHDB-896 https://issues.apache.org/jira/secure/attachment/12455783/couchdb-896.patch doesnt seem to be in trunk anymore On 14 April 2011 06:11, James ja...@howeswho.co.uk wrote: As of today, I'm getting exactly the same error in FF 4.0. Only known change on my system was a bunch of XP security updates. The couch I'm talking to is 1.0.1 on a different machine that has not changed.
Re: query_server_config
On Fri, Apr 15, 2011 at 2:50 PM, Jan Lehnardt j...@apache.org wrote: According to https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L277 you can't pass arbitrary options to the query server currently. I wouldn't say this is a bug, but it would be a nice feature :) Oh, I'd inspect sources more heartily before asking why(: Just thought that there is config options and query_config holder in State, so if not all options have passed there is something wrong. So, could it be requested?(: Probably, I see how-to solution via tracking query_server_config option set as json object to eliminate parsing and type casing problems which came from ini format, but for me there is two more problem to learn erlang and how couchdb internals work(: -- ,,,^..^,,,
Re: query_server_config
On 16 Apr 2011, at 17:54, Alexander Shorin wrote: On Fri, Apr 15, 2011 at 2:50 PM, Jan Lehnardt j...@apache.org wrote: According to https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L277 you can't pass arbitrary options to the query server currently. I wouldn't say this is a bug, but it would be a nice feature :) Oh, I'd inspect sources more heartily before asking why(: Just thought that there is config options and query_config holder in State, so if not all options have passed there is something wrong. So, could it be requested?(: Probably, I see how-to solution via tracking query_server_config option set as json object to eliminate parsing and type casing problems which came from ini format, but for me there is two more problem to learn erlang and how couchdb internals work(: Feel free to open a JIRA ticket* :) — This shouldn't be hard patch and it'd be great opportunity to dive into Erlang :) * http://issues.apache.org/jira/browse/COUCHDB Cheers Jan -- -- ,,,^..^,,,
Re: query_server_config
Thanks! So I'll have to try. On Sat, Apr 16, 2011 at 7:58 PM, Jan Lehnardt j...@apache.org wrote: On 16 Apr 2011, at 17:54, Alexander Shorin wrote: On Fri, Apr 15, 2011 at 2:50 PM, Jan Lehnardt j...@apache.org wrote: According to https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L277 you can't pass arbitrary options to the query server currently. I wouldn't say this is a bug, but it would be a nice feature :) Oh, I'd inspect sources more heartily before asking why(: Just thought that there is config options and query_config holder in State, so if not all options have passed there is something wrong. So, could it be requested?(: Probably, I see how-to solution via tracking query_server_config option set as json object to eliminate parsing and type casing problems which came from ini format, but for me there is two more problem to learn erlang and how couchdb internals work(: Feel free to open a JIRA ticket* :) — This shouldn't be hard patch and it'd be great opportunity to dive into Erlang :) * http://issues.apache.org/jira/browse/COUCHDB Cheers Jan -- -- ,,,^..^,,, -- ,,,^..^,,,
[jira] [Commented] (COUCHDB-1123) Longpolling changes feed with filter and accidental Content-Length header stalls
[
https://issues.apache.org/jira/browse/COUCHDB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020635#comment-13020635
]
Jan Lehnardt commented on COUCHDB-1123:
---
As per RFC2616 GEt requests can have a body and thus a valid Content-Length
header.
Technically, you are sending a malformed HTTP request. The question now is how
CouchDB should behave. I agree that the current behaviour is odd.
I'd propose that we respond with a 400 Bad Request, but I am happy for other
suggestions.
Fwiw, querying with a GET body does work as expected:
curl -X GET $COUCH'/a/_changes?filter=test/foofeed=longpoll'
-HContent-Length: 2 -d ab
{results:[
{seq:1,id:_design/test,changes:[{rev:1-0b4478e601ec850f0d3c009b9889917b}]},
{seq:2,id:3fb73daa9078091698c732c8130018be,changes:[{rev:1-23202479633c2b380f79507a776743d5}]}
],
last_seq:2}
Longpolling changes feed with filter and accidental Content-Length header
stalls
Key: COUCHDB-1123
URL: https://issues.apache.org/jira/browse/COUCHDB-1123
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0.2
Environment: Mac OS X Snow Leopard, Ubuntu 10.10.
Reporter: Jyrki Pulliainen
Priority: Minor
Labels: changes, contentlength, couchdb, header, http
CouchDB behaves erroneously when doing a GET request with Content-Length
header to long polling changes feed with filter set.
Easiest way to reproduce:
1. Create a new DB
2. Create a single design doc with a filter that just returns true
3. Query database with curl: curl -v -H Content-Length: 123
http://localhost:5984/database/_changes?feed=longpollfilter=designdoc/filter
At this point CouchDB behaves strangely. It does not wait for the client to
feed the Content-Length bytes of content (which I think is correct, since GET
should not have payload), instead, it returns 200 OK and starts the response
with '{results:['. However, no changes done to database ever get emitted
and the connection never gets closed, not even if explicit timeout is set
upon the request.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1116) Documentation for jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020637#comment-13020637 ] Jan Lehnardt commented on COUCHDB-1116: --- Not a whole lot .. a java dependency :D Not sure if I ever want to add that. But it may still be worth having the inline comments and produce the HTML outside of the regular build and pt it o the website. Documentation for jquery.couch.js - Key: COUCHDB-1116 URL: https://issues.apache.org/jira/browse/COUCHDB-1116 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Dale Harvey Priority: Minor Attachments: jquery.couch.js-docs.patch, jquery.couch.js-docs.patch Creating documentation for jquery.couch.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1016) $.couch.replicate throws error when cancelling continous replication
[
https://issues.apache.org/jira/browse/COUCHDB-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt resolved COUCHDB-1016.
---
Resolution: Fixed
Fix Version/s: 1.2
1.1
1.0.3
Committed, thanks.
$.couch.replicate throws error when cancelling continous replication
Key: COUCHDB-1016
URL: https://issues.apache.org/jira/browse/COUCHDB-1016
Project: CouchDB
Issue Type: Bug
Components: Replication
Reporter: Felix Hummel
Priority: Trivial
Fix For: 1.0.3, 1.1, 1.2
Calling $.couch.replicate with
{
continous: true,
cancel: true
}
results in an alert error message. Should be quiet and call success handler.
Patch:
diff --git a/share/www/script/jquery.couch.js
b/share/www/script/jquery.couch.js
index 114e580..14d2506 100644
--- a/share/www/script/jquery.couch.js
+++ b/share/www/script/jquery.couch.js
@@ -563,7 +563,7 @@
replicate: function(source, target, ajaxOptions, repOpts) {
repOpts = $.extend({source: source, target: target}, repOpts);
- if (repOpts.continuous) {
+ if (repOpts.continuous !repOpts.cancel) {
ajaxOptions.successStatus = 202;
}
ajax({
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1115) Added button to cancel continuous replications
[ https://issues.apache.org/jira/browse/COUCHDB-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020643#comment-13020643 ] Jan Lehnardt commented on COUCHDB-1115: --- I applied 1016, Egbert, do you want to clean up the patch? While you are at it, can you make sure the JS code is formatted like the rest in the file? Added button to cancel continuous replications -- Key: COUCHDB-1115 URL: https://issues.apache.org/jira/browse/COUCHDB-1115 Project: CouchDB Issue Type: Improvement Components: Futon Reporter: Egbert Teeselink Priority: Minor Labels: cancel, javascript, replication In response to a challenge from Jan Lehnart during the Berlin CouchDB training, I added a cancel link to the status page of Futon, so that running continuous replications can be cancelled. It can only cancel vanilla continuous replications, so ones that use filter functions or create_target will not work. I understood from Jan that this is fine, because later CouchDB versions will have sessions addressable as resources. Until then, this patch can cancel the continuous replications that Futon allows you to start. I wanted to try out github, so I forked and committed: https://github.com/eteeselink/couchdb/commit/e3295ed0d24b221206ef0f1cf75f78946297db31 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
[ https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson reassigned COUCHDB-1060: -- Assignee: Robert Newson CouchDB should use a secure password hash method instead of the current one --- Key: COUCHDB-1060 URL: https://issues.apache.org/jira/browse/COUCHDB-1060 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.0.2 Reporter: Nuutti Kotivuori Assignee: Robert Newson Priority: Minor Fix For: 1.2 Attachments: pbkdf2.erl, pbkdf2.erl CouchDB passwords are stored in a salted, hashed format of a 128-bit salt combined with the password under SHA-1. This method thwarts rainbow table attacks, but is utterly ineffective against any dictionary attacks as computing SHA-1 is very fast indeed. If passwords are to be stored in a non-plaintext equivalent format, the hash function needs to be a slow hash function. Suitable candidates for this could be bcrypt, scrypt and PBKDF2. Of the choices, only PBKDF2 is really widely used, standardized and goverment approved. (Note: don't be fooled that the PBKDF2 is a key derivation function - in this case, it is exactly the same thing as a slow password hash.) http://en.wikipedia.org/wiki/PBKDF2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
[ https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1060: --- Fix Version/s: 1.2 CouchDB should use a secure password hash method instead of the current one --- Key: COUCHDB-1060 URL: https://issues.apache.org/jira/browse/COUCHDB-1060 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.0.2 Reporter: Nuutti Kotivuori Assignee: Robert Newson Priority: Minor Fix For: 1.2 Attachments: pbkdf2.erl, pbkdf2.erl CouchDB passwords are stored in a salted, hashed format of a 128-bit salt combined with the password under SHA-1. This method thwarts rainbow table attacks, but is utterly ineffective against any dictionary attacks as computing SHA-1 is very fast indeed. If passwords are to be stored in a non-plaintext equivalent format, the hash function needs to be a slow hash function. Suitable candidates for this could be bcrypt, scrypt and PBKDF2. Of the choices, only PBKDF2 is really widely used, standardized and goverment approved. (Note: don't be fooled that the PBKDF2 is a key derivation function - in this case, it is exactly the same thing as a slow password hash.) http://en.wikipedia.org/wiki/PBKDF2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1113) GET requests fail against a list if they have content-type x-www-form-urlencoded
[
https://issues.apache.org/jira/browse/COUCHDB-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt resolved COUCHDB-1113.
---
Resolution: Fixed
Fix Version/s: 1.2
1.1
1.0.3
GET requests fail against a list if they have content-type
x-www-form-urlencoded
Key: COUCHDB-1113
URL: https://issues.apache.org/jira/browse/COUCHDB-1113
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0.2
Environment: all, but particularly JQuery
Reporter: Dennis Clark
Priority: Minor
Labels: erlang, javascript, list
Fix For: 1.0.3, 1.1, 1.2
Original Estimate: 2h
Remaining Estimate: 2h
Given a design doc like:
{
views: {whatever...}
lists: {myList: function (head, req) { ...}}
}
an ajax request in JQuery like:
$.get(/db/_design/ddoc/_list/myList/whatever, function (data) {...});
will fail with a 500 error of type function_clause. This appears to be
because CouchDB is attempting to parse the empty form it assumes must be
there based on the content type and mochiweb's parser fails.
Of course, if you try the same url in a browser or with curl, it'll work
perfectly.
This may be for deep reasons beyond my ken, but the silent failure of the
HTTP API in this case seems like a problem. At the very least, an informative
error message would be good.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1066) cookie_authentication_handler does not throw if cookie is invalid or has expired
[ https://issues.apache.org/jira/browse/COUCHDB-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020647#comment-13020647 ] Jan Lehnardt commented on COUCHDB-1066: --- Looks straightforward. +1. cookie_authentication_handler does not throw if cookie is invalid or has expired Key: COUCHDB-1066 URL: https://issues.apache.org/jira/browse/COUCHDB-1066 Project: CouchDB Issue Type: Bug Affects Versions: 0.11.2, 1.0.2, 1.1 Reporter: Robert Newson Assignee: Robert Newson Priority: Critical cookie_authentication_handler does not throw if the cookie is invalid or has expired, instead it delegates to the next handler. This leads to ugly results like getting a response from /_session but with no userCtx filled in. cookie_authentication_handler should throw if, and only if, there's an AuthSession cookie that is expired or invalid. We shouldn't attempt to try other auth schemes. If there is no such cookie, then we delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1116) Documentation for jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1116. --- Resolution: Fixed Fix Version/s: 1.2 Documentation for jquery.couch.js - Key: COUCHDB-1116 URL: https://issues.apache.org/jira/browse/COUCHDB-1116 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Dale Harvey Priority: Minor Fix For: 1.2 Attachments: jquery.couch.js-docs.patch, jquery.couch.js-docs.patch Creating documentation for jquery.couch.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1111) In Futon, links to documents with an id containing an ' are not escaped properly
[ https://issues.apache.org/jira/browse/COUCHDB-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-. --- Resolution: Fixed Fix Version/s: 1.2 1.1 1.0.3 In Futon, links to documents with an id containing an ' are not escaped properly Key: COUCHDB- URL: https://issues.apache.org/jira/browse/COUCHDB- Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.0.1, 1.0.2 Reporter: Nebu Pookins Fix For: 1.0.3, 1.1, 1.2 Steps to reproduce: 1) Create and save in Futon a new document with the 2-character ID a' 2) Return to the list of documents. 3) Click on the document you just created. Expected behaviour: You're brought to the document you selected. Actual behaviour: You get an error message The document could not be retrieved: missing Additional notes: All the quote characters seem to have been stripped from the HREF of the link, possibly due to incorrect escaping. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1106) After Mac OS X update can not connect to CouchDB (10.6.6 0 = 10.6.7)
[ https://issues.apache.org/jira/browse/COUCHDB-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020662#comment-13020662 ] Jan Lehnardt commented on COUCHDB-1106: --- Can you try starting couchdb as root? If that works, there's still permission issues. After Mac OS X update can not connect to CouchDB (10.6.6 0 = 10.6.7) - Key: COUCHDB-1106 URL: https://issues.apache.org/jira/browse/COUCHDB-1106 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.0.1, 1.0.2 Reporter: Aram Karapetyan Priority: Critical Labels: installation, mac, tcpport After updating Mac OS X to 10.6.7 had problem connecting to couchdb and noticed that it's running but not listening port. There are no logs. Even log file is missing and there is nothing in syslog. Launchctl is stopping starting correctly without any error. I used macports to install couchdb 4 months ago it was fine before update. I tried to remove everything somehow connected to couchdb and setup new one but result is same. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1108) expand options for since argument in _changes
[ https://issues.apache.org/jira/browse/COUCHDB-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020663#comment-13020663 ] Jan Lehnardt commented on COUCHDB-1108: --- +1, Randall, do you fancy updating your patch so it applies to trunk? expand options for since argument in _changes - Key: COUCHDB-1108 URL: https://issues.apache.org/jira/browse/COUCHDB-1108 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.0.2 Reporter: Thomas Vander Stichele Priority: Minor It would be useful to get continous _change feed from the current change_id. Now, if you only care about new changes, you have to first get the change_seq from the db, then ask for the _change feed with since=... since=current as an argument could be an option. Similarly, it might be useful to start with the last five changes (in all notification ways). for example, since=-5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1104) POST on a doc with the wrong id gives an obtuse error
[
https://issues.apache.org/jira/browse/COUCHDB-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt resolved COUCHDB-1104.
---
Resolution: Fixed
Fix Version/s: 1.2
This has been fixed in trunk a while ago.
POST on a doc with the wrong id gives an obtuse error
-
Key: COUCHDB-1104
URL: https://issues.apache.org/jira/browse/COUCHDB-1104
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.0.2
Environment: Linux
Reporter: Thomas Vander Stichele
Priority: Minor
Fix For: 1.2
Had this problem during a couchdb training.
[thomas@otto ~]$ curl -X GET
http://localhost:5984/bank/_all_docs{total_rows:5,offset:0,rows:[
{id:fe4a1382596a9071d66412f9f100183c,key:fe4a1382596a9071d66412f9f100183c,value:{rev:1-1e3f1ca41010f7cc641337fa3ea88593}},
{id:fe4a1382596a9071d66412f9f1001c67,key:fe4a1382596a9071d66412f9f1001c67,value:{rev:1-ea8b064f341943d19776e63201b6d0c4}},
{id:fe4a1382596a9071d66412f9f1002209,key:fe4a1382596a9071d66412f9f1002209,value:{rev:1-1c8d66f0baf7b022a63d62b99db5f133}},
{id:fe4a1382596a9071d66412f9f1002da8,key:fe4a1382596a9071d66412f9f1002da8,value:{rev:2-2d03d5121b4df02423cece5432de16cc}},
{id:fe4a1382596a9071d66412f9f100388a,key:fe4a1382596a9071d66412f9f100388a,value:{rev:1-e194aaf299e9ac452d2db072584271f6}}
]}
[thomas@otto ~]$ curl -X PUT -H Content-Type:image/jpeg
http://localhost:5984/bank/fe4a1382596a9071d66412f9f100183c/picture.jpg?rev=2-2d03d5121b4df02423cece5432de16cc;
--data-binary @ik/thomasvs.jpg
{error:{not_found,missing},reason:{2,45,3,213,18,27,77,240,36,35,206,206,84,50,222,22,204}}
[thomas@otto ~]$ curl -X PUT -H Content-Type:image/jpeg
http://localhost:5984/bank/fe4a1382596a9071d66412f9f100183c/picture.jpg?rev=1-1e3f1ca41010f7cc641337fa3ea88593;
--data-binary @ik/thomasvs.jpg
{ok:true,id:fe4a1382596a9071d66412f9f100183c,rev:2-650721e13f38e481e1839525cf0caa56}
The second command (first put) gives an unreadable reason. The reason is I
supplied a non-existing revid for that doc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1097) Unable to do an OPTIONS request to shows or lists
[ https://issues.apache.org/jira/browse/COUCHDB-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020667#comment-13020667 ] Jan Lehnardt commented on COUCHDB-1097: --- Looking good, can you add tests to that? Unable to do an OPTIONS request to shows or lists - Key: COUCHDB-1097 URL: https://issues.apache.org/jira/browse/COUCHDB-1097 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.0.2 Reporter: Omar Yasin Priority: Minor Labels: http When using XHR to access CouchDB, it is not possible to respond to OPTIONS requests for shows or lists. This means that it's impossible for to tell the requesting browsers which communication options are available causing it to throw a Access-Control-Allow error. I've patched this in my github fork of CouchDB at: https://github.com/omarkj/couchdb/commit/a11ba543581c05d61b031d044bad9f9d63c875c0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1090) jquery.couch.js enforces cache option
[
https://issues.apache.org/jira/browse/COUCHDB-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020669#comment-13020669
]
Jan Lehnardt commented on COUCHDB-1090:
---
I remember this has been in for a long time, I'm hesitant to just remove the
option, how about an override:
diff --git a/share/www/script/jquery.couch.js b/share/www/script/jquery.couch.js
index 9e31cef..3fbd0d1 100644
--- a/share/www/script/jquery.couch.js
+++ b/share/www/script/jquery.couch.js
@@ -1025,7 +1025,7 @@
ajaxOptions = $.extend({contentType: application/json}, ajaxOptions);
errorMessage = errorMessage || Unknown error;
$.ajax($.extend($.extend({
- type: GET, dataType: json, cache : !$.browser.msie,
+ type: GET, dataType: json, cache : options.cache || !$.browser.msie,
beforeSend: function(xhr){
if(ajaxOptions ajaxOptions.headers){
for (var header in ajaxOptions.headers){
jquery.couch.js enforces cache option
-
Key: COUCHDB-1090
URL: https://issues.apache.org/jira/browse/COUCHDB-1090
Project: CouchDB
Issue Type: Bug
Components: Infrastructure
Reporter: Dale Harvey
Priority: Trivial
Attachments: cache.patch
jquery.couch.js explicitly sets a cache, preventing the programmer from being
able to set it
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1086) Improve config file write-back behavior.
[ https://issues.apache.org/jira/browse/COUCHDB-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020670#comment-13020670 ] Jan Lehnardt commented on COUCHDB-1086: --- local.ini should take precedence. I'm a bit hazy on the use-case for local.d if we never write back to anything but local.ini. Maybe it was though that plugins could have their own write-back files, but CouchDB doesn't support any of that. Maybe Noah remembers? Either way, geocouch.ini should go in default.d. Improve config file write-back behavior. - Key: COUCHDB-1086 URL: https://issues.apache.org/jira/browse/COUCHDB-1086 Project: CouchDB Issue Type: Improvement Components: Futon Environment: Ubuntu 10.04 Reporter: Michael Wiederhold Priority: Minor 1) I install couchdb and change the bind address in default.ini to 0.0.0.0 so I can access couch remotely. 2) In futon I change the bind address to 127.0.0.1 and then refresh the web page an the web ui disappears. 3) I go back into the config file default.ini and the bind address is still 0.0.0.0. 4) I then go into local.ini and there is nothing except for comments. 5) I restart the server and it binds to 127.0.0.1 and I cannot see futon. The issue is that when changing the bind address in futon, futon puts the new address in the config file with the highest priority which is in this case the geocouch config file, but the proper place to put the new bind address is in local.ini. I marked this as critical because I can see it affecting a decent amount of users. Should be a quick fix. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1079) Fix local version append
[ https://issues.apache.org/jira/browse/COUCHDB-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1079. --- Resolution: Fixed Fix Version/s: 1.2 Fixing this in trunk, let's see if it breaks anything :) Fix local version append Key: COUCHDB-1079 URL: https://issues.apache.org/jira/browse/COUCHDB-1079 Project: CouchDB Issue Type: Bug Reporter: Paul Joseph Davis Fix For: 1.2 The local version info is awesome to be able to track down exactly what commit someone has built locally with, but the way that info is appended caused some confusion: 1.2.0ac052866-git I tried a handful of git sha's from that info before I broke down and read the bootstrap and acinclude.m4.in sources to figure out what was going on. It turns out, the version info is: 1 (Major) 2 (Minor) 0 (Revision) a (Alpha) (c052866-git) (Local) As you might guess, figuring out why Git was telling me that revisions 0ac052886 and ac052886 was mildly irritating. I would propose we just add a dot to separate the local part as in: 1.2.0a.c052886-git I'd commit this but I figured I should go ahead and see if anyone has any objections first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1078) Port couchjs to newest libmozjs
[ https://issues.apache.org/jira/browse/COUCHDB-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020674#comment-13020674 ] Jan Lehnardt commented on COUCHDB-1078: --- Can we make it that both 1.1 and 1.2 will compile with everything that currently compile with in addition to the new release? I don't think we should drop existing compat with 1.2. Port couchjs to newest libmozjs --- Key: COUCHDB-1078 URL: https://issues.apache.org/jira/browse/COUCHDB-1078 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Affects Versions: 1.0.2 Reporter: Chris Coulson Priority: Minor Attachments: COUCHDB-1078.patch, couchjs_ff185.patch, mozjs2.0.patch In the libmozjs shipped with Firefox 4 / xulrunner 2.0, jsapi has changed a fair bit. It would be nice to add support to couchjs for the latest libmozjs so Linux distro's don't have to support old versions of it. I already have a WIP patch for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1082) Fix a typo and confusing comment in 050-stream.t
[ https://issues.apache.org/jira/browse/COUCHDB-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020675#comment-13020675 ] Jan Lehnardt commented on COUCHDB-1082: --- Before we fix the comment, we should make sure the code isn't wrong :) Fix a typo and confusing comment in 050-stream.t Key: COUCHDB-1082 URL: https://issues.apache.org/jira/browse/COUCHDB-1082 Project: CouchDB Issue Type: Test Components: Test Suite Affects Versions: 1.1 Reporter: Andrey Somov Priority: Trivial Labels: test-patch Attachments: 1082-patch.txt, oneBits.jpg Original Estimate: 0.5h Remaining Estimate: 0.5h The comment says Successfully wrote 80 1 bits. while in fact they are (almost) all zeros. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1059) jquery couch list function and html response
[
https://issues.apache.org/jira/browse/COUCHDB-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020677#comment-13020677
]
Jan Lehnardt commented on COUCHDB-1059:
---
A patch would be great :)
jquery couch list function and html response
Key: COUCHDB-1059
URL: https://issues.apache.org/jira/browse/COUCHDB-1059
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.0.1
Reporter: Ronen
Calling a list function from jquery couch that returns a non json response
(html in my case) fails since the return type is hardcoded as json:
complete: function(req) {
try {
var resp = $.httpData(req,json);
} catch(e) {
//
This causes httpData to try and parse the returned data as json, by making
this optional (adding returnType option to options):
var resp = $.httpData(req, options.returnType?
options.returnType:json);
It is solved,
I can create a patch if required.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1073) DELETE _session doesn't delete the session. Client can still get user information using GET _session and with the session cookie retrieved.
[ https://issues.apache.org/jira/browse/COUCHDB-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1073. --- Resolution: Not A Problem Since CouchDB doesn't track any /_session state, an explicit logout isn't possible. The default timeout for sessions is 10 minutes, if that is a hazard, you can reduce it in the config. DELETE _session doesn't delete the session. Client can still get user information using GET _session and with the session cookie retrieved. --- Key: COUCHDB-1073 URL: https://issues.apache.org/jira/browse/COUCHDB-1073 Project: CouchDB Issue Type: Improvement Reporter: Johnny Weng Luu When using DELETE _session CouchDB only sends a empty session cookie back. But if I use the original session cookie when using GET _session I can still get the user information. https://gist.github.com/838996 This could be a security flaw because when the user leaves the computer a hacker can check out the session cookie and log in to account. Very bad if it's a very sensitive web application like financial. Isn't it better to just delete the session internally in couchdb when DELETE _session is used. Then that session cookie the hacker gets won't matter because the session is already gone. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1059) jquery couch list function and html response
[
https://issues.apache.org/jira/browse/COUCHDB-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020679#comment-13020679
]
Jan Lehnardt commented on COUCHDB-1059:
---
This would be a patch:
diff --git a/share/www/script/jquery.couch.js b/share/www/script/jquery.couch.js
index 9e31cef..c62ab9e 100644
--- a/share/www/script/jquery.couch.js
+++ b/share/www/script/jquery.couch.js
@@ -1024,8 +1024,9 @@
options = $.extend({successStatus: 200}, options);
ajaxOptions = $.extend({contentType: application/json}, ajaxOptions);
errorMessage = errorMessage || Unknown error;
+var dataType = options.returnType ? options.returnType : json;
$.ajax($.extend($.extend({
- type: GET, dataType: json, cache : !$.browser.msie,
+ type: GET, dataType: dataType, cache : !$.browser.msie,
beforeSend: function(xhr){
if(ajaxOptions ajaxOptions.headers){
for (var header in ajaxOptions.headers){
@@ -1035,7 +1036,7 @@
},
complete: function(req) {
try {
- var resp = httpData(req, json);
+ var resp = httpData(req, dataType);
} catch(e) {
if (options.error) {
options.error(req.status, req, e);
jquery couch list function and html response
Key: COUCHDB-1059
URL: https://issues.apache.org/jira/browse/COUCHDB-1059
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.0.1
Reporter: Ronen
Calling a list function from jquery couch that returns a non json response
(html in my case) fails since the return type is hardcoded as json:
complete: function(req) {
try {
var resp = $.httpData(req,json);
} catch(e) {
//
This causes httpData to try and parse the returned data as json, by making
this optional (adding returnType option to options):
var resp = $.httpData(req, options.returnType?
options.returnType:json);
It is solved,
I can create a patch if required.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1077) bulkSave() method in couch.js generates more UUIDs than are needed.
[ https://issues.apache.org/jira/browse/COUCHDB-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1077. --- Resolution: Fixed Fix Version/s: 1.2 Fixed in trunk. bulkSave() method in couch.js generates more UUIDs than are needed. --- Key: COUCHDB-1077 URL: https://issues.apache.org/jira/browse/COUCHDB-1077 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.0.1 Environment: Ubuntu 10.10 Reporter: James Henstridge Priority: Minor Fix For: 1.2 The code in bulkSave() to fill in the _id attribute of documents that are missing it generates more UUIDs than needed. It first counts the number of documents that lack the _id attribute, but instead of using this value when calling CouchDB.newUuids(), it instead uses the total number of documents. This doesn't result in incorrect results, but is wasted effort. If all the documents already have IDs, then it also adds an unnecessary round trip. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1040) Needs more information about running replications
[ https://issues.apache.org/jira/browse/COUCHDB-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1040. --- Resolution: Fixed Fix Version/s: 1.1 The replicator_db in 1.1 should do the trick :) Needs more information about running replications - Key: COUCHDB-1040 URL: https://issues.apache.org/jira/browse/COUCHDB-1040 Project: CouchDB Issue Type: New Feature Components: Replication Environment: all Reporter: Alexey Loshkarev Priority: Minor Fix For: 1.1 It will be nice to have more information about running replications to check and handle them correctly. For example, i started tens replication from test to test2 with continious flag and different filter functions. It may run for a weeks. And how to recognize, if one of them is failed and i need to restart only one of them? Thank you. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1020) 202 status on DELETE /db
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1020. --- Resolution: Won't Fix Fix Version/s: (was: 1.2) 202 status on DELETE /db -- Key: COUCHDB-1020 URL: https://issues.apache.org/jira/browse/COUCHDB-1020 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.2 Reporter: Benoit Chesneau Priority: Minor Current status is 200 . Following irc discussion there are 2 points of you considering tthat sicne db isn't accessible from HTTP api, 200 is ok. But still data is on the disk and effectively, deletion is asynchronous. HTTP Spec on DELETE : [[[ A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. ]]] and status 202 : [[[ The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled. ]]] Since it's true that deletion introduce an aysnchronous process to delete the db file an it's data, I think that 202 is more appropriate here. 202 would mean, that resource isn't available but deletion is running. Related to #COUCHDB-1019 we could pass a pid or taskid to the response eventually. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1014) Make prepareUserDoc a public method of $.couch
[ https://issues.apache.org/jira/browse/COUCHDB-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1014. --- Resolution: Fixed Fix Version/s: 1.2 1.1 Make prepareUserDoc a public method of $.couch -- Key: COUCHDB-1014 URL: https://issues.apache.org/jira/browse/COUCHDB-1014 Project: CouchDB Issue Type: Improvement Components: Futon Reporter: Benjamin Young Priority: Trivial Fix For: 1.1, 1.2 Attachments: prepareUserDoc.patch Original Estimate: 0h Remaining Estimate: 0h The prepareUserDoc function is a helpful feature of jquery.couch.js, but it's currently a private/hidden function. This patch makes it a public method of $.couch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1015) Add Change Password feature to Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1015. --- Resolution: Fixed Fix Version/s: 1.2 1.1 Add Change Password feature to Futon -- Key: COUCHDB-1015 URL: https://issues.apache.org/jira/browse/COUCHDB-1015 Project: CouchDB Issue Type: New Feature Components: Futon Reporter: Benjamin Young Fix For: 1.1, 1.2 Attachments: change_password_in_futon.patch This patch allows users to change their passwords from a link in the sidebar of Futon. It depends on the prepeareUserDoc patch attached to #1014. Passwords can be change for both _user members and _admin users. Once the password is change the user is re-authenticated with the same password without needing to login again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1004) list_to_existing_atom is too restrictive as used by couch_rep
[ https://issues.apache.org/jira/browse/COUCHDB-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-1004: -- Fix Version/s: 1.2 1.1 1.0.3 Bump, should we get this into 1.0.3/1.1.0 now? list_to_existing_atom is too restrictive as used by couch_rep - Key: COUCHDB-1004 URL: https://issues.apache.org/jira/browse/COUCHDB-1004 Project: CouchDB Issue Type: Bug Components: Replication Environment: erlang Reporter: Bob Dionne Priority: Minor Fix For: 1.0.3, 1.1, 1.2 Attachments: COUCHDB-1004.patch We'd like to additional information to db_info in BigCouch, such as the Q and N constants for a given database. This causes replication to fail when replicating from BigCouch to CouchDB due to the use of list_to_existing_atom in couch_rep:dbinfo(... The claim is that list_to_atom pollutes the atoms table, however superficial testing indicates this is not the case, list_to_atom when called repeatedly seems to work fine. If this is true then consider reverting list_to_existing_atom back to list_to_atom. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1001) The Replicator page could be enhanced by displaying a list of past and current replication tasks (esp. continuous replication)
[ https://issues.apache.org/jira/browse/COUCHDB-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020683#comment-13020683 ] Jan Lehnardt commented on COUCHDB-1001: --- Benoit, what patch didn't we review? The Replicator page could be enhanced by displaying a list of past and current replication tasks (esp. continuous replication) -- Key: COUCHDB-1001 URL: https://issues.apache.org/jira/browse/COUCHDB-1001 Project: CouchDB Issue Type: Improvement Components: Futon Affects Versions: 1.0 Reporter: Fil Original Estimate: 1h Remaining Estimate: 1h The Replicator page could be enhanced by displaying a list of past and current replication tasks (esp. continuous replication). (This list currently can be found in the Status page, and is difficult to understand.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-997) Prevent multiple keys from entering a btree.
[ https://issues.apache.org/jira/browse/COUCHDB-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020684#comment-13020684 ] Jan Lehnardt commented on COUCHDB-997: -- Do we have a conclusion here? Prevent multiple keys from entering a btree. Key: COUCHDB-997 URL: https://issues.apache.org/jira/browse/COUCHDB-997 Project: CouchDB Issue Type: Bug Reporter: Paul Joseph Davis s/sort/usort/ at https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_btree.erl#L181 This should be completely transparent and incur minimal overhead. This hasn't bitten us quite yet, but it would've prevented some of the crazier behavior from COUCHDB-968 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-967) CouchDB create database response error is wrong
[ https://issues.apache.org/jira/browse/COUCHDB-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-967. -- Resolution: Not A Problem The docs state Note also that a / character in a DB name must be escaped when used in a URL; CouchDB create database response error is wrong --- Key: COUCHDB-967 URL: https://issues.apache.org/jira/browse/COUCHDB-967 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.0.2, 1.1, 1.2, 2.0 Environment: Mac OS X Snow Leopard Reporter: Filippo Fadda Priority: Minor When you try to create a database with a / inside name, the following error is returned. For example: Database name: /invalid/name/ _ using cURL _ http://127.0.0.1:5984/invalid/name/ HTTP Status Code: 404 Not Found CouchDB Error: not_found CouchDB Reason: no_db_file Now, the documentation says: A database must be named with all lowercase letters (a-z), digits (0-9), or any of the _$()+-/ characters and must end with a slash in the URL. The name has to start with a lowercase letter (a-z). But we know that a database name can't contain the / character, but it must end with /. So the documentation is wrong and the reported error is wrong too. CouchDB infast must report the same error provided when you try to create a database named Invalidname with the first letter uppercase, like in the following example: Database name: /Invalidname/ _ using cURL _ http://127.0.0.1:5984/Invalidname/ HTTP Status Code: 400 Bad Request CouchDB Error: illegal_database_name CouchDB Reason: Only lowercase characters (a-z), digits (0-9), and any of the characters _, $, (, ), +, -, and / are allowed. Must begin with a letter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-946) Calling the /_restart API via socket or cURL, sometimes CouchDB restarts before I can get the response headers.
[
https://issues.apache.org/jira/browse/COUCHDB-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt resolved COUCHDB-946.
--
Resolution: Incomplete
No feedback, closing.
Calling the /_restart API via socket or cURL, sometimes CouchDB restarts
before I can get the response headers.
-
Key: COUCHDB-946
URL: https://issues.apache.org/jira/browse/COUCHDB-946
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1, 1.2
Environment: Mac OS X 10.6.5
Reporter: Filippo Fadda
Calling the /_restart API via socket or cURL, sometimes CouchDB restarts
before I can get the response headers. Not always, sometimes.
Additionally, with a restart cycle, calling the API sequentially, sometimes
CouchDB crashes with a bus error or seg fault.
/_restart
_ using socket _
string(6) 200 OK
array(5) {
[Server]=
string(31) CouchDB/1.0.1 (Erlang OTP/R14B)
[Date]=
string(29) Fri, 12 Nov 2010 04:07:47 GMT
[Content-Type]=
string(24) text/plain;charset=utf-8
[Content-Length]=
string(2) 12
[Cache-Control]=
string(15) must-revalidate
}
/_restart
_ using socket _
Error code: 0
Message: HTTP Status Code undefined.
/_restart
_ using cURL _
string(6) 200 OK
array(5) {
[Server]=
string(31) CouchDB/1.0.1 (Erlang OTP/R14B)
[Date]=
string(29) Fri, 12 Nov 2010 04:13:04 GMT
[Content-Type]=
string(24) text/plain;charset=utf-8
[Content-Length]=
string(2) 12
[Cache-Control]=
string(15) must-revalidate
}
/_restart
_ using cURL _
Error code: 0
Message: Empty reply from server
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1110) obtuse error when specifying a wrong filter for replication
[
https://issues.apache.org/jira/browse/COUCHDB-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt resolved COUCHDB-1110.
---
Resolution: Duplicate
obtuse error when specifying a wrong filter for replication
---
Key: COUCHDB-1110
URL: https://issues.apache.org/jira/browse/COUCHDB-1110
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Affects Versions: 1.0.2
Reporter: Thomas Vander Stichele
Priority: Minor
In a training, I did:
curl -X POST -H Content-Type: application/json -d '{source: bank,
target: customers, filter: design_doc/customers}'
http://localhost:5984/_replicate
{error:changes_loop_died}
The backtrace in couchdb is really long.
Apparently I should have used demo instead of design_doc.
I think couchdb should simply tell me that the filter does not exist.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-939) Upload handlers do not parse multipart form data.
[ https://issues.apache.org/jira/browse/COUCHDB-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-939. -- Resolution: Not A Problem Form parsing happens on application/x-www-form-urlencoded. Upload handlers do not parse multipart form data. - Key: COUCHDB-939 URL: https://issues.apache.org/jira/browse/COUCHDB-939 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.0.1 Environment: OS X 10.6.4, CouchDBX. Reporter: Evan Krall 1. Submit to an _update handler using a form enctype=multipart/form-data 2. Inspect the update function's request.form attribute Expected result: request.form has attributes corresponding to the different input fields in the form. Actual result: request.form has no attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-919) Add build options
[ https://issues.apache.org/jira/browse/COUCHDB-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-919. -- Resolution: Not A Problem Closing until there are specific issues raised that can only be solved by adding this. Add build options - Key: COUCHDB-919 URL: https://issues.apache.org/jira/browse/COUCHDB-919 Project: CouchDB Issue Type: Improvement Components: Build System Affects Versions: 1.0.1 Environment: *.nix, OS X Reporter: Tracy Flynn Priority: Minor Add some build options to support non-default organization of CouchDB dependencies. If /usr/local is taken as an example for the default installation directory (prefix) for CouchDB, then the installation works without modification only if other dependencies are configured and built with the same prefix. Some options allow the changing of the location of the dependency - e.g. --with-js-lib for Spidermonkey The standard set appears to be: --with-erlang=PATH set PATH to the Erlang include directory --with-js-include=PATH set PATH to the SpiderMonkey include directory --with-js-lib=PATH set PATH to the SpiderMonkey library directory --with-openssl-bin-dir=PATH path to the open ssl binaries for distribution on Windows A suggestion for others that would help with dependencies in non-standard location: --with-openssl-dir - for the general OpenSSL case --with-icu-dir=xxx (might need a greater number of options - I'm not familiar with the full feature set for ICU) --with-curl-dir=xxx -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-923) Server-Side Includes
[ https://issues.apache.org/jira/browse/COUCHDB-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-923. -- Resolution: Won't Fix I don't see how this should work. Server-Side Includes Key: COUCHDB-923 URL: https://issues.apache.org/jira/browse/COUCHDB-923 Project: CouchDB Issue Type: New Feature Environment: n/a Reporter: Dominic Barnes Priority: Minor This is just a would-be-nice feature especially for CouchApp developers like myself. A server-side includes system (much like Apache's) would be extremely useful in the context of CouchApps. I think being able to pull in a global header and footer within an HTML file itself would be a great addition, rather than having to either integrate it into my show/list functions, as well as any static HTML files within my design document. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-929) jsonp test fails with '1. Assertion failed: xhr.status == 400'
[ https://issues.apache.org/jira/browse/COUCHDB-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-929. Resolution: Cannot Reproduce Haven't seen this in a while. Closing. jsonp test fails with '1. Assertion failed: xhr.status == 400' -- Key: COUCHDB-929 URL: https://issues.apache.org/jira/browse/COUCHDB-929 Project: CouchDB Issue Type: Bug Components: Test Suite Affects Versions: 1.0.1 Environment: Ubuntu Linux 10.10 Reporter: Hrunting Johnson The jsonp test fails with '1. Assertion failed: xhr.status == 400' reproducibly every time. When running the test under Firefox, it's the last xhr.status check that fails, which is a GET of the following URL: /test_suite_db/_design/test/_view/all_docs?callback=jsonp_chunk' Firebug reports that the URL fetched is: /test_suite_db/_design/test/_view/all_docs?callback=jsonp_chunk%27 When running under Chrome, it's the first xhr.status check that fails, which is a GET of the following URL: /test_suite_db/0?callback=foo In both cases, the test expects to receive a status code of 400 and gets a status code of 200. Firefox appears to be failing because it's actually getting back a 304 Not Modified and using a cached result. Chrome is getting back a 200 response from the server with an actual JSON result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1059) jquery couch list function and html response
[
https://issues.apache.org/jira/browse/COUCHDB-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020695#comment-13020695
]
Ronen commented on COUCHDB-1059:
Sorry I didn't see your response up till now, I guess that your covered
Thanks for the fix
Ronen
jquery couch list function and html response
Key: COUCHDB-1059
URL: https://issues.apache.org/jira/browse/COUCHDB-1059
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.0.1
Reporter: Ronen
Calling a list function from jquery couch that returns a non json response
(html in my case) fails since the return type is hardcoded as json:
complete: function(req) {
try {
var resp = $.httpData(req,json);
} catch(e) {
//
This causes httpData to try and parse the returned data as json, by making
this optional (adding returnType option to options):
var resp = $.httpData(req, options.returnType?
options.returnType:json);
It is solved,
I can create a patch if required.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-866) cookie_auth test fail
[
https://issues.apache.org/jira/browse/COUCHDB-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt resolved COUCHDB-866.
--
Resolution: Cannot Reproduce
I can't reproduce this. Please reopen if this still fails with either 1.0.x,
1.1.x or trunk.
cookie_auth test fail
-
Key: COUCHDB-866
URL: https://issues.apache.org/jira/browse/COUCHDB-866
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Affects Versions: 1.0, 1.0.1
Environment: Firefox 3.6.6 without any extensions
Mac OSX 10.6.4
Reporter: christian kirkegaard
Priority: Minor
cookie_auth test fail every time with the same error. I have cookies enabled
but nothing seems to fix this. Ive even tried different browsers with
somewhat same report.
firefox,
{message:ddoc is
null,fileName:http://127.0.0.1:5984/_utils/script/test/cookie_auth.js,lineNumber:41,stack:;()@http://127.0.0.1:5984/_utils/script/test/cookie_auth.js:41\u000arun_on_modified_server([object
Array],(function () {try {var usersDb = new CouchDB(\test_suite_users\,
{'X-Couch-Full-Commit': \false\});usersDb.deleteDb();usersDb.createDb();var
ddoc = usersDb.open(\_design/_auth\);T(ddoc.validate_doc_update);var
password = \3.141592653589\;var jasonUserDoc =
CouchDB.prepareUserDoc({name: \Jason Davies\, roles: [\dev\]},
password);T(usersDb.save(jasonUserDoc).ok);var checkDoc =
usersDb.open(jasonUserDoc._id);T(checkDoc.name == \Jason Davies\);var
jchrisUserDoc = CouchDB.prepareUserDoc({name: \jch...@apache.org\},
\funnybone\);T(usersDb.save(jchrisUserDoc).ok);var duplicateJchrisDoc =
CouchDB.prepareUserDoc({name: \jch...@apache.org\}, \eh, Boo-Boo?\);try
{usersDb.save(duplicateJchrisDoc);T(false \Can't create duplicate user
names. Should have thrown an error.\);} catch (e) {T(e.error ==
\conflict\);T(usersDb.last_req.status == 409);}var underscoreUserDoc =
CouchDB.prepareUserDoc({name: \_why\}, \copperfield\);try
{usersDb.save(underscoreUserDoc);T(false \Can't create underscore user
names. Should have thrown an error.\);} catch (e) {T(e.error ==
\forbidden\);T(usersDb.last_req.status == 403);}var badIdDoc =
CouchDB.prepareUserDoc({name: \foo\}, \bar\);badIdDoc._id =
\org.apache.couchdb:w00x\;try {usersDb.save(badIdDoc);T(false \Can't
create malformed docids. Should have thrown an error.\);} catch (e)
{T(e.error == \forbidden\);T(usersDb.last_req.status ==
403);}T(CouchDB.login(\Jason Davies\,
password).ok);T(CouchDB.session().userCtx.name == \Jason
Davies\);jasonUserDoc.foo =
2;T(usersDb.save(jasonUserDoc).ok);T(CouchDB.session().userCtx.roles.indexOf(\_admin\)
== -1);try {usersDb.deleteDoc(jchrisUserDoc);T(false \Can't delete other
users docs. Should have thrown an error.\);} catch (e) {T(e.error ==
\forbidden\);T(usersDb.last_req.status == 403);}T(!CouchDB.login(\Jason
Davies\, \2.71828\).ok);T(!CouchDB.login(\Robert Allen Zimmerman\,
\d00d\).ok);T(CouchDB.session().userCtx.name != \Jason Davies\);xhr =
CouchDB.request(\POST\, \/_session?next=/\, {headers: {'Content-Type':
\application/x-www-form-urlencoded\}, body:
\name=Jason%20Daviespassword=\ + encodeURIComponent(password)});if
(xhr.status == 200) {T(/Welcome/.test(xhr.responseText));} else {T(xhr.status
==
302);T(xhr.getResponseHeader(\Location\));}T(CouchDB.login(\jch...@apache.org\,
\funnybone\).ok);T(CouchDB.session().userCtx.name ==
\jch...@apache.org\);T(CouchDB.session().userCtx.roles.length ==
0);jasonUserDoc.foo = 3;try {usersDb.save(jasonUserDoc);T(false \Can't
update someone else's user doc. Should have thrown an error.\);} catch (e)
{T(e.error == \forbidden\);T(usersDb.last_req.status ==
403);}jchrisUserDoc.roles = [\foo\];try
{usersDb.save(jchrisUserDoc);T(false \Can't set roles unless you are
admin. Should have thrown an error.\);} catch (e) {T(e.error ==
\forbidden\);T(usersDb.last_req.status ==
403);}T(CouchDB.logout().ok);T(CouchDB.session().userCtx.roles[0] ==
\_admin\);jchrisUserDoc.foo =
[\foo\];T(usersDb.save(jchrisUserDoc).ok);jchrisUserDoc.roles =
[\_bar\];try {usersDb.save(jchrisUserDoc);T(false \Can't add system
roles to user's db. Should have thrown an error.\);} catch (e) {T(e.error ==
\forbidden\);T(usersDb.last_req.status ==
403);}T(CouchDB.login(\jch...@apache.org\,
\funnybone\).ok);T(CouchDB.session().userCtx.name ==
\jch...@apache.org\);T(CouchDB.session().userCtx.roles.indexOf(\_admin\)
== -1);T(CouchDB.session().userCtx.roles.indexOf(\foo\) !=
-1);T(CouchDB.logout().ok);T(CouchDB.session().userCtx.roles[0] ==
\_admin\);T(CouchDB.session().userCtx.name ==
null);run_on_modified_server([{section: \admins\, key:
\jch...@apache.org\, value: \funnybone\}], function ()
{T(CouchDB.login(\jch...@apache.org\,
\funnybone\).ok);T(CouchDB.session().userCtx.name ==
[jira] [Commented] (COUCHDB-859) Replication test failure on CouchDB 1.0.1 / Ubuntu 10.04 / Xulrunner 1.0.2.8 clean install
[
https://issues.apache.org/jira/browse/COUCHDB-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020697#comment-13020697
]
Jan Lehnardt commented on COUCHDB-859:
--
Can you try 1.0.2?
Replication test failure on CouchDB 1.0.1 / Ubuntu 10.04 / Xulrunner 1.0.2.8
clean install
--
Key: COUCHDB-859
URL: https://issues.apache.org/jira/browse/COUCHDB-859
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Ubuntu 10.04 (Rackspace Cloud 1024 MB Server Instance) /
Xulrunner 1.0.2.8 clean installation
Reporter: David Pitman
I've spent the day getting the perfect install (for my needs) of CouchDB
1.0.1. After initially finding that nothing in the test suite worked and
remote replication in either direction was broken (local replication works
fine), I started on a clean server instance and made sure Xulrunner was
1.9.2.8 instead of 1.9.2.3 (which was my original configuration). Once that
was in place, all tests in the Futon Test Suite are working fine - except
for the replication test. Which gives this error:
Exception raised: {\message\:\Cannot read property 'Content-Type' of
undefined\,\stack\:\TypeError: Cannot read property 'Content-Type' of
undefined\\nat Function.request (
http://174.143.xxx.xxx/_utils/script/couch.js?0.11.0:402:52)\\nat
[object Object].afterAB1 (eval at patchTest (
http://174.143.xxx.xxx/_utils/script/couch_test_runner.js?0.11.0:37:5))\\n
at eval at patchTest (
http://174.143.xxx.xxx/_utils/script/couch_test_runner.js?0.11.0:37:5)\\n
at run (
http://174.143.xxx.xxx/_utils/script/couch_test_runner.js?0.11.0:84:7
)\,\type\:\non_object_property_load\,\arguments\:[\Content-Type\,null]}
I just changed the IP address to protect the awesome Admin party that's
going on over there.
The linux environment is a Ubuntu 10.04 server instance over at Rackspace
Cloud Servers. It is completely stock except for Xulrunner + CouchDB
installed from source as per the directions at
http://wiki.apache.org/couchdb/Installing_on_Ubuntu
CouchDB without replication is a bit of a lame duck. Replication is not
working at all, not just the Test Suite execution, I can't even do a push
replication from another couchdb server instance into this one.
I have a separate install of 0.11.2 on the same environment and everything
is working just fine.
Thanks.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-997) Prevent multiple keys from entering a btree.
[ https://issues.apache.org/jira/browse/COUCHDB-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020700#comment-13020700 ] Paul Joseph Davis commented on COUCHDB-997: --- Kinda. We ended up just fixing the other bug. And then forgot that this was open. So it was kind of a cliff hanger conclusion due to May sweeps. Prevent multiple keys from entering a btree. Key: COUCHDB-997 URL: https://issues.apache.org/jira/browse/COUCHDB-997 Project: CouchDB Issue Type: Bug Reporter: Paul Joseph Davis s/sort/usort/ at https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_btree.erl#L181 This should be completely transparent and incur minimal overhead. This hasn't bitten us quite yet, but it would've prevented some of the crazier behavior from COUCHDB-968 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1108) expand options for since argument in _changes
[ https://issues.apache.org/jira/browse/COUCHDB-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020708#comment-13020708 ] Randall Leeds commented on COUCHDB-1108: Surely. Will do with tests, thanks. expand options for since argument in _changes - Key: COUCHDB-1108 URL: https://issues.apache.org/jira/browse/COUCHDB-1108 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.0.2 Reporter: Thomas Vander Stichele Priority: Minor It would be useful to get continous _change feed from the current change_id. Now, if you only care about new changes, you have to first get the change_seq from the db, then ask for the _change feed with since=... since=current as an argument could be an option. Similarly, it might be useful to start with the last five changes (in all notification ways). for example, since=-5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1090) jquery.couch.js enforces cache option
[
https://issues.apache.org/jira/browse/COUCHDB-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020719#comment-13020719
]
Dale Harvey commented on COUCHDB-1090:
--
the reason I took it out completely is that it already is an option
$.ajaxSetup({
cache: false
});
and it can be passed through the options as long as it isnt set explicity, I
would say its up to jquery to specify sensible defaults and if futon wants no
cache in ie it can add it itself, I am happy either way though as long as the
developer can specify
jquery.couch.js enforces cache option
-
Key: COUCHDB-1090
URL: https://issues.apache.org/jira/browse/COUCHDB-1090
Project: CouchDB
Issue Type: Bug
Components: Infrastructure
Reporter: Dale Harvey
Priority: Trivial
Attachments: cache.patch
jquery.couch.js explicitly sets a cache, preventing the programmer from being
able to set it
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
