[jira] [Closed] (COUCHDB-3433) rename "bylaws" to "community guidelines"
[ https://issues.apache.org/jira/browse/COUCHDB-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-3433. Resolution: Fixed > rename "bylaws" to "community guidelines" > - > > Key: COUCHDB-3433 > URL: https://issues.apache.org/jira/browse/COUCHDB-3433 > Project: CouchDB > Issue Type: Task >Reporter: Naomi Slater >Priority: Major > > see here: > [https://lists.apache.org/thread.html/e5a17e8263dbc8efdd7e20978d653f3ede6c5488c4970d545d340d7f@%3Cdiversity.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COUCHDB-3226) Build under snap container is denied access to /bindf
[ https://issues.apache.org/jira/browse/COUCHDB-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629108#comment-16629108 ] Joan Touzet commented on COUCHDB-3226: -- Hi [~sklassen], Michael doesn't work for Ubuntu anymore and has no involvement in snap stuff. Any attempts we've made to reach him haven't resulted in a response, so you're probably on your own here. If you're struggling with snap stuff, you might want to try reaching out directly to an Ubuntu support channel rather than Michael :) -Joan > Build under snap container is denied access to /bindf > - > > Key: COUCHDB-3226 > URL: https://issues.apache.org/jira/browse/COUCHDB-3226 > Project: CouchDB > Issue Type: Bug > Components: Build System >Reporter: Simon C Klassen >Priority: Major > > dmesg is logging "audit: type=1400 audit(1478517224.548:198): > apparmor="DENIED" operation="exec" profile="snap.couchdb.couchdb" > name="/bin/df" pid=16227 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 > ouid=0" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416301#comment-16416301 ] Joan Touzet commented on COUCHDB-2594: -- Thanks [~janl] - i always get confused because the wiki tag for you is janl. _Mea culpa._ > Single node mode: remove warning > > > Key: COUCHDB-2594 > URL: https://issues.apache.org/jira/browse/COUCHDB-2594 > Project: CouchDB > Issue Type: Task > Components: Database Core >Reporter: Robert Kowalski >Priority: Minor > Labels: has-pr > Fix For: 2.0.1 > > > we have to remove a warning that is sent as response if the node is not > joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-2594. Resolution: Fixed > Single node mode: remove warning > > > Key: COUCHDB-2594 > URL: https://issues.apache.org/jira/browse/COUCHDB-2594 > Project: CouchDB > Issue Type: Task > Components: Database Core >Reporter: Robert Kowalski >Priority: Minor > Labels: has-pr > Fix For: 2.0.1 > > > we have to remove a warning that is sent as response if the node is not > joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416165#comment-16416165 ] Joan Touzet commented on COUCHDB-2594: -- Looks like [~janl] incorrectly used "j...@apache.org" for some of these commits over in GitHub, which doesn't map to any user, so the integration INFRA has set up picked whomever was the first alphabetical match, which was you. Sorry about that! It shouldn't happen again, this code is now merged, but if it does, you and I could open an INFRA ticket. > Single node mode: remove warning > > > Key: COUCHDB-2594 > URL: https://issues.apache.org/jira/browse/COUCHDB-2594 > Project: CouchDB > Issue Type: Task > Components: Database Core >Reporter: Robert Kowalski >Priority: Minor > Labels: has-pr > Fix For: 2.0.1 > > > we have to remove a warning that is sent as response if the node is not > joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COUCHDB-3393) Function lookup() - script can ask for documents!
[
https://issues.apache.org/jira/browse/COUCHDB-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3393.
Resolution: Won't Fix
> Function lookup() - script can ask for documents!
> -
>
> Key: COUCHDB-3393
> URL: https://issues.apache.org/jira/browse/COUCHDB-3393
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core
>Reporter: Ondřej Novák
>
> This is not just a feature request, this is proof of concept. Working with
> query servers, i wondered why the functions list() and show() cannot asks for
> additional documents. Sticking with one document (show) or one view(list)
> very limiting these rendering functions.
> CouchDB also doesn't support join operation with more then one reference hop
> and only with include_docs (which is not supported for reduce). Giving to the
> script some lookup function can break many these limitations (INCLUDING
> REDUCED RESULTS!)
> After some research, i found a way, how the query server can ask the the
> database for the documents. So I downloaded couchdb sources and tried to
> implement my idea. And it worked.
> From the javascript, there is a new function available for the Render section
> (show, list, update).
> {noformat}
> function lookup(docs[]) -> array
> {noformat}
> The function accepts list of doc-ids. It returns whole document for every
> doc-id in the array. Asking for non-existing documen, or deleted document
> causes that null is returned.
> How is this implemented?
> The query server can return a command instead of a regular response.
> {noformat}
> ["lookup", [docs]]
> {noformat}
> The couchdb performs lookup for the specified documents and returns them
> through the proc_prompt back to the query server. Then the couchdb repeats
> the waiting for the regular response. The above situation can repeat as many
> times as needed.
> The following log was created on my development version of couchdb. You can
> see "lookup" function in the action.
> {noformat}
> [debug] [<0.163.0>] OS Process #Port<0.3023> Input ::
> ["ddoc","_design/example",["shows","test"],[null,{..}]]
> [debug] [<0.163.0>] OS Process #Port<0.3023> Output ::
> ["lookup",["doc1","doc2","doc3"]]
> [debug] [<0.163.0>] OS Process #Port<0.3023> Input ::
> [true,[{"_id":"doc1","_rev":"1-7ef1a0ad6b5aae5c716ed7969c87fe97","payload":"aaa"},null,null]]
> [debug] [<0.163.0>] OS Process #Port<0.3023> Output ::
> ["resp",{"body":"[{\"_id\":\"doc1\",\"_rev\":\"1-7ef1a0ad6b5aae5c716ed7969c87fe97\",\"payload\":\"aaa\"},null,null]"}]
> {noformat}
> I hope this new feature can improve scripting a lot!
> I have implemented this feature in the branch 1.6.x, because i have this
> version in the production. You can find the patch below. It would be probably
> easy to port the patch to the master branch.
> I would appreciate if somebody look at this concept and perhaps improve my
> implementation and include it to the future version.
> Diff to 1.6.x
> {noformat}
> diff --git a/share/server/loop.js b/share/server/loop.js
> index 644d89b..886afb3 100644
> --- a/share/server/loop.js
> +++ b/share/server/loop.js
> @@ -28,6 +28,7 @@ function init_sandbox() {
> sandbox.send = Render.send;
> sandbox.getRow = Render.getRow;
> sandbox.isArray = isArray;
> +sandbox.lookup = Render.lookup;
>} catch (e) {
> //log(e.toSource());
>}
> diff --git a/share/server/render.js b/share/server/render.js
> index 49b0863..3384fd0 100644
> --- a/share/server/render.js
> +++ b/share/server/render.js
> @@ -195,6 +195,18 @@ var Render = (function() {
> return json[1];
>};
>
> +
> + function lookup(docs) {
> + respond(["lookup", docs]);
> + var json = JSON.parse(readline());
> + if (json[0] == true) {
> + return json[1];
> + } else {
> + return null;
> + }
> +};
> +
> +
>
>function maybeWrapResponse(resp) {
> var type = typeof resp;
> @@ -337,6 +349,7 @@ var Render = (function() {
> start : start,
> send : send,
> getRow : getRow,
> +lookup: lookup,
> show : function(fun, ddoc, args) {
>// var showFun = Couch.compileFunction(funSrc);
>runShow(fun, ddoc, args);
> diff --git a/src/couch_mrview/src/couch_mrview_show.erl
> b/src/couch_mrview/src/couch_mrview_show.erl
> index f8fa837..fe1eaca 100644
> --- a/src/couch_mrview/src/couch_mrview_show.erl
> +++ b/src/couch_mrview/src/couch_mrview_show.erl
> @@ -86,8 +86,7 @@ handle_doc_show(Req, Db, DDoc, ShowName, Doc, DocId) ->
> couch_httpd:etag_respond(Req, CurrentEtag, fun() ->
> JsonReq = couch_httpd_external:json_req_obj(Req, Db, DocId),
> JsonDoc = couch_query_servers:json_doc(Doc),
> -[<<"resp">>, ExternalResp] =
> -couch_query_servers:ddoc_prompt(DDoc,
[jira] [Commented] (COUCHDB-2995) Can't build CouchDB on Smartos
[
https://issues.apache.org/jira/browse/COUCHDB-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201495#comment-16201495
]
Joan Touzet commented on COUCHDB-2995:
--
Hi Andreas,
Yes, it is. You shouldn't be using port 5986 for *+anything+* other than when
you are explicitly instructed to do so via the documentation. I am not
surprised at all that your tests don't work if you're trying to run the tests
from port 5986. Port 5986 should further never be bound to anything other than
{{localhost}} for security purposes.
I recommend comparing the built output of `make release` on Linux/OSX/Windows
vs. your build and seeing where things are supposed to be installed.
Once you figure that out, retry the validation process using
http://localhost:5984/_utils/ .
> Can't build CouchDB on Smartos
> --
>
> Key: COUCHDB-2995
> URL: https://issues.apache.org/jira/browse/COUCHDB-2995
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Affects Versions: 2.0.0
>Reporter: Noah Mehl
> Attachments: a.log, couchdb.tgz, rebar.config.script.diff,
> rebar.config.script.diff, rebar2.config.script.diff
>
>
> When I try to build CouchDB on SmartOS, I get the following output:
> ./configure --prefix=/opt/local
> ==> configuring couchdb in rel/couchdb.config
> Cloning into '/opt/local/src/couchdb/src/rebar'...
> remote: Counting objects: 367, done.
> remote: Compressing objects: 100% (249/249), done.
> remote: Total 367 (delta 60), reused 363 (delta 59)
> Receiving objects: 100% (367/367), 241.62 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (60/60), done.
> Checking connectivity... done.
> Note: checking out '5dea85db1b697466586877bed133748bd80fa180'.
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
> git checkout -b
> make: Entering directory '/opt/local/src/couchdb/src/rebar'
> ./bootstrap
> Recompile: src/rebar
> Recompile: src/rebar_abnfc_compiler
> Recompile: src/rebar_app_utils
> Recompile: src/rebar_appups
> Recompile: src/rebar_asn1_compiler
> Recompile: src/rebar_base_compiler
> Recompile: src/rebar_cleaner
> Recompile: src/rebar_config
> Recompile: src/rebar_core
> Recompile: src/rebar_cover_utils
> Recompile: src/rebar_ct
> Recompile: src/rebar_deps
> Recompile: src/rebar_dia_compiler
> Recompile: src/rebar_dialyzer
> Recompile: src/rebar_edoc
> Recompile: src/rebar_erlc_compiler
> Recompile: src/rebar_erlydtl_compiler
> Recompile: src/rebar_escripter
> Recompile: src/rebar_eunit
> Recompile: src/rebar_file_utils
> Recompile: src/rebar_getopt
> Recompile: src/rebar_lfe_compiler
> Recompile: src/rebar_log
> Recompile: src/rebar_metacmds
> Recompile: src/rebar_mustache
> Recompile: src/rebar_neotoma_compiler
> Recompile: src/rebar_otp_app
> Recompile: src/rebar_otp_appup
> Recompile: src/rebar_port_compiler
> Recompile: src/rebar_proto_compiler
> Recompile: src/rebar_proto_gpb_compiler
> Recompile: src/rebar_protobuffs_compiler
> Recompile: src/rebar_qc
> Recompile: src/rebar_rel_utils
> Recompile: src/rebar_reltool
> Recompile: src/rebar_require_vsn
> Recompile: src/rebar_shell
> Recompile: src/rebar_subdirs
> Recompile: src/rebar_templater
> Recompile: src/rebar_upgrade
> Recompile: src/rebar_utils
> Recompile: src/rebar_xref
> Recompile: src/rmemo
> ==> rebar (compile)
> ==> rebar (escriptize)
> Congratulations! You now have a self-contained script called "rebar" in
> your current working directory. Place this script anywhere in your path
> and you can use rebar to build OTP-compliant apps.
> make: Leaving directory '/opt/local/src/couchdb/src/rebar'
> make: Entering directory '/opt/local/src/couchdb/src/rebar'
> make: Leaving directory '/opt/local/src/couchdb/src/rebar'
> ==> updating dependencies
> WARN: Expected /opt/local/src/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN: Expected /opt/local/src/couchdb/src/fauxton to be a raw dependency
> directory, but no directory found.
> ==> rel (get-deps)
> ==> couchdb (get-deps)
> WARN: Expected /opt/local/src/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN: Expected /opt/local/src/couchdb/src/fauxton to be a raw dependency
> directory, but no directory found.
> Pulling couch_epi from
> {git,"https://git-wip-us.apache.org/repos/asf/couchdb-couch-epi.git;,
> "5a7f2868c720bc428e6c888dc61d988b9a5f63f1"}
> Cloning into 'couch_epi'...
> Pulling config from
> {git,"https://git-wip-us.apache.org/repos/asf/couchdb-config.git;,
>
[jira] [Commented] (COUCHDB-2995) Can't build CouchDB on Smartos
[
https://issues.apache.org/jira/browse/COUCHDB-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200854#comment-16200854
]
Joan Touzet commented on COUCHDB-2995:
--
OK, looks like couchjs is OK.
Here is the relevant part of the log:
{code}
[debug] 2017-10-11T18:28:44.205783Z couchdb@localhost <0.13818.2>
'POST' /_replicate {1,1} from "192.168.178.32"
Headers: [{'Accept',"application/json, text/javascript, */*;
q=0.01"},{'Accept-Encoding',"gzip,
deflate"},{'Accept-Language',"de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4"},{'Connection',"keep-alive"},{'Content-Length',"80"},{'Content-Type',"application/json"},{'Host',"192.168.178.21:5986"},{"Origin","http://192.168.178.21:5986"},{'Referer',"http://192.168.178.21:5986/_utils/"},{'User-Agent',"Mozilla/5.0
(Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/61.0.3163.102 Safari/537.36
Vivaldi/1.93.955.38"},{"X-Requested-With","XMLHttpRequest"}]
[error] 2017-10-11T18:28:44.213641Z couchdb@localhost <0.13818.2>
Uncaught error in HTTP request: {error,undef}
[info] 2017-10-11T18:28:44.213817Z couchdb@localhost <0.13818.2>
Stacktrace:
[{couch_replicator_httpd_utils,validate_rep_props,[[{<<"create_target">>,true},{<<"source">>,<<"verifytestdb">>},{<<"target">>,<<"verifytestdb_replicate">>}]],[]},{couch_replicator_httpd,handle_req,1,[{file,"src/couch_replicator_httpd.erl"},{line,92}]},{couch_httpd,handle_request_int,5,[{file,"src/couch_httpd.erl"},{line,317}]},{mochiweb_http,headers,6,[{file,"src/mochiweb_http.erl"},{line,91}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]
[notice] 2017-10-11T18:28:44.214034Z couchdb@localhost <0.13818.2>
192.168.178.32 - - POST /_replicate 500
[error] 2017-10-11T18:28:44.214234Z couchdb@localhost <0.13818.2>
httpd 500 error response:
{"error":"unknown_error","reason":"undef"}
{code}
That's a pretty basic thing to be failing. What version of CouchDB are you
building? If 2.0, have you tried against 2.1? And which version of Erlang are
you using? Have you patched the source code to do anything different beyond the
{{rebar.config}} changes for Solaris builds?
A better thing to try would be to run {{make check}} at the top-level of
CouchDB and see if all of the tests pass. That is a more exhaustive test than
the "sanity test" you can try through Fauxton.
> Can't build CouchDB on Smartos
> --
>
> Key: COUCHDB-2995
> URL: https://issues.apache.org/jira/browse/COUCHDB-2995
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Affects Versions: 2.0.0
>Reporter: Noah Mehl
> Attachments: a.log, couchdb.tgz, rebar.config.script.diff,
> rebar.config.script.diff, rebar2.config.script.diff
>
>
> When I try to build CouchDB on SmartOS, I get the following output:
> ./configure --prefix=/opt/local
> ==> configuring couchdb in rel/couchdb.config
> Cloning into '/opt/local/src/couchdb/src/rebar'...
> remote: Counting objects: 367, done.
> remote: Compressing objects: 100% (249/249), done.
> remote: Total 367 (delta 60), reused 363 (delta 59)
> Receiving objects: 100% (367/367), 241.62 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (60/60), done.
> Checking connectivity... done.
> Note: checking out '5dea85db1b697466586877bed133748bd80fa180'.
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
> git checkout -b
> make: Entering directory '/opt/local/src/couchdb/src/rebar'
> ./bootstrap
> Recompile: src/rebar
> Recompile: src/rebar_abnfc_compiler
> Recompile: src/rebar_app_utils
> Recompile: src/rebar_appups
> Recompile: src/rebar_asn1_compiler
> Recompile: src/rebar_base_compiler
> Recompile: src/rebar_cleaner
> Recompile: src/rebar_config
> Recompile: src/rebar_core
> Recompile: src/rebar_cover_utils
> Recompile: src/rebar_ct
> Recompile: src/rebar_deps
> Recompile: src/rebar_dia_compiler
> Recompile: src/rebar_dialyzer
> Recompile: src/rebar_edoc
> Recompile: src/rebar_erlc_compiler
> Recompile: src/rebar_erlydtl_compiler
> Recompile: src/rebar_escripter
> Recompile: src/rebar_eunit
> Recompile: src/rebar_file_utils
> Recompile: src/rebar_getopt
> Recompile: src/rebar_lfe_compiler
> Recompile: src/rebar_log
> Recompile: src/rebar_metacmds
> Recompile: src/rebar_mustache
> Recompile: src/rebar_neotoma_compiler
> Recompile: src/rebar_otp_app
> Recompile: src/rebar_otp_appup
> Recompile: src/rebar_port_compiler
> Recompile: src/rebar_proto_compiler
> Recompile: src/rebar_proto_gpb_compiler
> Recompile: src/rebar_protobuffs_compiler
>
[jira] [Commented] (COUCHDB-2995) Can't build CouchDB on Smartos
[
https://issues.apache.org/jira/browse/COUCHDB-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200512#comment-16200512
]
Joan Touzet commented on COUCHDB-2995:
--
"Verify CouchDB Installation" shouldn't fail at all. Replication should be
possible in a 1-node system.
Your error means that, most likely, couchjs isn't working, which is probably
still related to SpiderMonkey not working correctly, probably due to a bitness
mismatch (couchjs being built 64-bit vs. SM being a 32-bit library).
I wouldn't release this in your current state.
> Can't build CouchDB on Smartos
> --
>
> Key: COUCHDB-2995
> URL: https://issues.apache.org/jira/browse/COUCHDB-2995
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Affects Versions: 2.0.0
>Reporter: Noah Mehl
> Attachments: rebar.config.script.diff, rebar.config.script.diff,
> rebar2.config.script.diff
>
>
> When I try to build CouchDB on SmartOS, I get the following output:
> ./configure --prefix=/opt/local
> ==> configuring couchdb in rel/couchdb.config
> Cloning into '/opt/local/src/couchdb/src/rebar'...
> remote: Counting objects: 367, done.
> remote: Compressing objects: 100% (249/249), done.
> remote: Total 367 (delta 60), reused 363 (delta 59)
> Receiving objects: 100% (367/367), 241.62 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (60/60), done.
> Checking connectivity... done.
> Note: checking out '5dea85db1b697466586877bed133748bd80fa180'.
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
> git checkout -b
> make: Entering directory '/opt/local/src/couchdb/src/rebar'
> ./bootstrap
> Recompile: src/rebar
> Recompile: src/rebar_abnfc_compiler
> Recompile: src/rebar_app_utils
> Recompile: src/rebar_appups
> Recompile: src/rebar_asn1_compiler
> Recompile: src/rebar_base_compiler
> Recompile: src/rebar_cleaner
> Recompile: src/rebar_config
> Recompile: src/rebar_core
> Recompile: src/rebar_cover_utils
> Recompile: src/rebar_ct
> Recompile: src/rebar_deps
> Recompile: src/rebar_dia_compiler
> Recompile: src/rebar_dialyzer
> Recompile: src/rebar_edoc
> Recompile: src/rebar_erlc_compiler
> Recompile: src/rebar_erlydtl_compiler
> Recompile: src/rebar_escripter
> Recompile: src/rebar_eunit
> Recompile: src/rebar_file_utils
> Recompile: src/rebar_getopt
> Recompile: src/rebar_lfe_compiler
> Recompile: src/rebar_log
> Recompile: src/rebar_metacmds
> Recompile: src/rebar_mustache
> Recompile: src/rebar_neotoma_compiler
> Recompile: src/rebar_otp_app
> Recompile: src/rebar_otp_appup
> Recompile: src/rebar_port_compiler
> Recompile: src/rebar_proto_compiler
> Recompile: src/rebar_proto_gpb_compiler
> Recompile: src/rebar_protobuffs_compiler
> Recompile: src/rebar_qc
> Recompile: src/rebar_rel_utils
> Recompile: src/rebar_reltool
> Recompile: src/rebar_require_vsn
> Recompile: src/rebar_shell
> Recompile: src/rebar_subdirs
> Recompile: src/rebar_templater
> Recompile: src/rebar_upgrade
> Recompile: src/rebar_utils
> Recompile: src/rebar_xref
> Recompile: src/rmemo
> ==> rebar (compile)
> ==> rebar (escriptize)
> Congratulations! You now have a self-contained script called "rebar" in
> your current working directory. Place this script anywhere in your path
> and you can use rebar to build OTP-compliant apps.
> make: Leaving directory '/opt/local/src/couchdb/src/rebar'
> make: Entering directory '/opt/local/src/couchdb/src/rebar'
> make: Leaving directory '/opt/local/src/couchdb/src/rebar'
> ==> updating dependencies
> WARN: Expected /opt/local/src/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN: Expected /opt/local/src/couchdb/src/fauxton to be a raw dependency
> directory, but no directory found.
> ==> rel (get-deps)
> ==> couchdb (get-deps)
> WARN: Expected /opt/local/src/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN: Expected /opt/local/src/couchdb/src/fauxton to be a raw dependency
> directory, but no directory found.
> Pulling couch_epi from
> {git,"https://git-wip-us.apache.org/repos/asf/couchdb-couch-epi.git;,
> "5a7f2868c720bc428e6c888dc61d988b9a5f63f1"}
> Cloning into 'couch_epi'...
> Pulling config from
> {git,"https://git-wip-us.apache.org/repos/asf/couchdb-config.git;,
> "a2d5ad2eedc960248b806f61df0a1009462bdb46"}
> Cloning into 'config'...
> Pulling b64url from
> {git,"https://git-wip-us.apache.org/repos/asf/couchdb-b64url.git;,
> "319fc604235ab1fde37047b38a432450161db750"}
>
[jira] [Closed] (COUCHDB-2484) replication crashes
[
https://issues.apache.org/jira/browse/COUCHDB-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-2484.
Resolution: Auto Closed
> replication crashes
> ---
>
> Key: COUCHDB-2484
> URL: https://issues.apache.org/jira/browse/COUCHDB-2484
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 1.x.x
>Reporter: Gunther Gruber
>
> We are Using Couchdb Version 1.2.0 with 8.3T of data, biggest Database ist
> 2.1T. At this moment we switch to new hardware with more storage space. We
> copied the files with rsync and started the replication.
> One system is already in sync, the other is doing the replication.
> I appreciate that besides the errors in the log, the first system is now in
> sync.
> The log looks like the following
> Retrying POST request to http://replication:/database/_revs_diff in 0.5
> seconds due to error req_timedout
> and then
> Mon, 01 Dec 2014 13:00:28 GMT] [error] [<0.27044.1>] ** Generic server
> <0.27044.1> terminating
> ** Last message in was {'EXIT',<0.26965.1>,killed}
> ** When Server state == {state,<0.26965.1>,<0.27045.1>,40,
> {httpdb,
> "http://replication:XXX@XXX.5984/sm_chemie/;,
> nil,
> [{"Accept","application/json"},
> {"User-Agent","CouchDB/1.2.0"}],
> 3,
> [{socket_options,
> [{recbuf,262144},
> {sndbuf,262144},
> {nodelay,true},
> {keepalive,true}]}],
> 10,250,<0.26966.1>,40},
> {httpdb,
> "http://replication:XXX@XXX:5984/sm_chemie/;,
> nil,
> [{"Accept","application/json"},
> {"User-Agent","CouchDB/1.2.0"}],
> 3,
> [{socket_options,
> [{recbuf,262144},
> {sndbuf,262144},
> {nodelay,true},
> {keepalive,true}]}],
> 10,250,<0.26968.1>,40},
> [],nil,nil,nil,
> {rep_stats,0,0,0,0,0},
> nil,nil,
> {batch,[],0}}
> ** Reason for termination ==
> ** killed
> [Mon, 01 Dec 2014 13:00:28 GMT] [error] [<0.27042.1>] {error_report,<0.31.0>,
>{<0.27042.1>,crash_report,
> [[{initial_call,
>{couch_replicator_worker,init,['Argument__1']}},
> {pid,<0.27042.1>},
> {registered_name,[]},
> {error_info,
>{exit,killed,
> [{gen_server,terminate,6,
> [{file,"gen_server.erl"},{line,747}]},
> {proc_lib,init_p_do_apply,3,
> [{file,"proc_lib.erl"},{line,227}]}]}},
> {ancestors,
>[<0.26965.1>,couch_rep_sup,couch_primary_services,
> couch_server_sup,<0.32.0>]},
> {messages,[]},
> {links,[<0.27043.1>]},
> {dictionary,
>[{last_stats_report,{1417,438797,704976}}]},
> {trap_exit,true},
> {status,running},
> {heap_size,377},
> {stack_size,24},
> {reductions,372}],
> []]}}
> It seems to me like a timeout and the replication task then exits. I allready
> played arround with the configuration setting with no succes. I can provide
> more information if needed.
> /etc/couchdb/local.d/001-user_config.ini
> [couchdb]
> file_compression = snappy
> max_dbs_open = 400
> [httpd]
> bind_address = ::
> server_options = [{backlog, 128}, {acceptor_pool_size, 16}]
> socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true},
> {keepalive, true}]
> [couch_httpd_auth]
> secret =
> [log_level_by_module]
> couch_httpd = warning
> couch_replicator = debug
> couch_query_servers = warning
> [daemons]
> httpsd = {couch_httpd, start_link, [https]}
> [ssl]
> cert_file = /etc/couchdb/ssl/certs/couchdb-couch1.prime.adns.de.pem
> key_file =
[jira] [Closed] (COUCHDB-3221) Shard maps for reserved database names cannot be updated
[ https://issues.apache.org/jira/browse/COUCHDB-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-3221. Resolution: Auto Closed Migrated to https://github.com/apache/couchdb/issues/858 > Shard maps for reserved database names cannot be updated > > > Key: COUCHDB-3221 > URL: https://issues.apache.org/jira/browse/COUCHDB-3221 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 2.0.0 >Reporter: Simon Keary > > I'm still seeing the same problem as described in COUCHDB-2424 with CouchDB > 2.0.0 (Ubuntu) but it doesn't appear that I can reopen that issue. > What I'm trying to do trying to get a newly added cluster node to participate > in all the databases already created in the cluster so that I can then remove > an existing node and replace it with the new one. The workflow I have is: > * Add the new node to the cluster using the _nodes endpoint. This works. > * For each database edit the shard metadata document (e.g. _db/db_name) and > add all shards to the new node. > This appears to work for all databases except the system databases. > Essentially this means that you can't move the shards for these database off > a node in order to retire that node. > An easy way to reproduce the issue is to open > http://localhost:5986/_utils/#/database/_dbs/_metadata and then click "Save > Changes" in Fauxton. The error "Save failed: Only reserved document ids may > start with underscore." is displayed. Doing the same process for a user > database works fine. Similarly, editing the document via curl also fails with > the same error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (COUCHDB-3414) Support Erlang 20.0
[
https://issues.apache.org/jira/browse/COUCHDB-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3414.
Resolution: Auto Closed
Moved to https://github.com/apache/couchdb/issues/617
> Support Erlang 20.0
> ---
>
> Key: COUCHDB-3414
> URL: https://issues.apache.org/jira/browse/COUCHDB-3414
> Project: CouchDB
> Issue Type: New Feature
>Reporter: Alexander F Rødseth
>
> Hi,
> I'm maintaining erlang for Arch Linux. Recently, our package for erlang 19.3
> was patched in connection with the upgrade to OpenSSL 1.1.0. Normally we
> don't patch packages but try to keep them as close to the upstream release as
> possible, but this was security related and therefore prioritized. Most
> things related to Erlang continued to work fine, but CouchDB didn't and a bug
> was reported in the Arch Linux bug tracker.
> 3 days ago, Erlang released version 20.0 rc1, which included the desired
> changes related to OpenSSL 1.1.0. I released a version of this package to
> [community-testing]. This looks promising.
> As far as I am aware, the current situation is that couchdb does not run on
> Arch Linux at all, right now.
> When compiling couchdb with Erlang 20.0 rc1, I get:
> ==> couch_epi (compile)
> ERROR: OTP release 20 does not match required regex R16B03|R16B03-1|17|18|19
> ERROR: compile failed while processing
> /build/couchdb/src/apache-couchdb-2.0.0/src/couch_epi: rebar_abort
> make: *** [Makefile:67: couch] Error 1
> Please support Erlang 20.0.
> Related bug report: https://bugs.archlinux.org/task/53499
> Cheers,
> Alexander F Rødseth
> Edit:
> Error message when running, from Bruno Pagani at
> https://bugs.archlinux.org/task/53499:
> [os_mon] memory supervisor port (memsup): Erlang has closed
> [os_mon] cpu supervisor port (cpu_sup): Erlang has closed
> {"Kernel pid
> terminated",application_controller,"{application_start_failure,couch_epi,{{shutdown,{failed_to_start_child,\"couch_epi|chttpd_auth|keeper\",{undef,[{crypto,md5,[<<131,106>>],[]},{couch_epi_util,hash,1,[{file,\"src/couch_epi_util.erl\"},{line,25}]},{couch_epi_functions,data,1,[{file,\"src/couch_epi_functions.erl\"},{line,33}]},{couch_epi_module_keeper,do_reload_if_updated,1,[{file,\"src/couch_epi_module_keeper.erl\"},{line,116}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,247}]}]}}},{couch_epi_app,start,[normal,[]]}}}"}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3319) Unable to modify cors/methods to enable HTTP OPTIONS requests
[
https://issues.apache.org/jira/browse/COUCHDB-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169048#comment-16169048
]
Joan Touzet commented on COUCHDB-3319:
--
There is special handling for OPTIONS - CouchDB should be handling CORS
preflight requests correctly.
The code is here:
https://github.com/apache/couchdb/blob/f4c6113808d1809469df9c8be9d2f83ef399f064/src/chttpd/src/chttpd_cors.erl
The list of supported headers is here:
https://github.com/apache/couchdb/blob/f4c6113808d1809469df9c8be9d2f83ef399f064/src/chttpd/include/chttpd_cors.hrl
I see some headers in your request that are not in the list of supported
headers. Can you retry your request with curl, and only the headers as
specified in the SUPPORTED_HEADERS list and see if it succeeds? We may have to
expand the list to include e.g. headers set automatically by the user agent.
> Unable to modify cors/methods to enable HTTP OPTIONS requests
> -
>
> Key: COUCHDB-3319
> URL: https://issues.apache.org/jira/browse/COUCHDB-3319
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Peter Wilmott
>
> I'm running CouchDB 2.0.0 and in '/opt/couchdb/etc/local.d/local.ini' I have
> the following:
> {quote}
> ; CouchDB Configuration Settings
> ; Custom settings should be made in this file. They will override settings
> ; in default.ini, but unlike changes made to default.ini, this file won't be
> ; overwritten on server upgrade.
> [chttpd]
> bind_address = any
> [couchdb]
> uuid = e5675a08388ac8563d4b8e8d46e96d42
> [httpd]
> enable_cors = true
> [cors]
> origins = *
> methods = GET, POST, PUT, DELETE, OPTIONS
> {quote}
> The documentation indicates that 'cors/methods' is used to control which HTTP
> methods will be accepted:
> http://docs.couchdb.org/en/2.0.0/config/http.html?highlight=enable_cors#cors/methods
> However when I make an OPTIONS request I receive '405 Method Not Allowed' as
> a response. Additionally the response contains the following in it's headers:
> {quote}
> Allow:DELETE,GET,HEAD,POST,PUT,COPY
> {quote}
> Which seems to indicate that my configuration is not being used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3432) make fails at jiffy
[
https://issues.apache.org/jira/browse/COUCHDB-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079379#comment-16079379
]
Joan Touzet commented on COUCHDB-3432:
--
Weird, that got corrupted. It shouild say:
the output of the command which c++ is /bin/c++
That file is identical to /bin/g++.
> make fails at jiffy
> ---
>
> Key: COUCHDB-3432
> URL: https://issues.apache.org/jira/browse/COUCHDB-3432
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Reporter: Nicholas Chandoke
>
> On CentOS 7. {{[g]make release}} fails:
> {quote}==> couch_epi (compile)
> [. . .]
> ==> ioq (compile)
> ==> jiffy (compile)
> Compiling /home/n/apache-couchdb-2.0.0/src/jiffy/c_src/doubles.cc
> sh: line 0: exec: c++: not found
> ERROR: compile failed while processing
> /home/n/apache-couchdb-2.0.0/src/jiffy: rebar_abort
> gmake: *** [couch] Error 1{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3432) make fails at jiffy
[
https://issues.apache.org/jira/browse/COUCHDB-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079377#comment-16079377
]
Joan Touzet commented on COUCHDB-3432:
--
On my CentOS 7 machine, the output of the command "which c++" is "/bin/c++".
That file is identical to /bin/g++ (checking the md5sums).
If you don't have g++ installed then you are missing the g++ build dependency,
which is provided by the RPM gcc-c++ (yum install gcc-c++ should fix it.)
If you do have g++ installed then you could try running `ln -s /bin/g++
/bin/c++` as root, then retrying your build.
> make fails at jiffy
> ---
>
> Key: COUCHDB-3432
> URL: https://issues.apache.org/jira/browse/COUCHDB-3432
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Reporter: Nicholas Chandoke
>
> On CentOS 7. {{[g]make release}} fails:
> {quote}==> couch_epi (compile)
> [. . .]
> ==> ioq (compile)
> ==> jiffy (compile)
> Compiling /home/n/apache-couchdb-2.0.0/src/jiffy/c_src/doubles.cc
> sh: line 0: exec: c++: not found
> ERROR: compile failed while processing
> /home/n/apache-couchdb-2.0.0/src/jiffy: rebar_abort
> gmake: *** [couch] Error 1{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3431) 400 error when posting valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3431.
Resolution: Fixed
> 400 error when posting valid JSON
> -
>
> Key: COUCHDB-3431
> URL: https://issues.apache.org/jira/browse/COUCHDB-3431
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: glen
>
> Is anything invalid about the first member of an array being an empty object?
> Please post [{}] to your Couch. Does your Couch return invalid json 400
> error, or is it just me?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3431) 400 error when posting valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078936#comment-16078936
]
Joan Touzet commented on COUCHDB-3431:
--
Reopening just to note that we even state this in the response:
$ curl -X PUT localhost:15984/foo/bar -d '[{}]'
{"error":"bad_request","reason":"Document must be a JSON object"}
Even though what you are posting is valid JSON, it is not a valid CouchDB
document. Sorry.
> 400 error when posting valid JSON
> -
>
> Key: COUCHDB-3431
> URL: https://issues.apache.org/jira/browse/COUCHDB-3431
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: glen
>
> Is anything invalid about the first member of an array being an empty object?
> Please post [{}] to your Couch. Does your Couch return invalid json 400
> error, or is it just me?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (COUCHDB-3431) 400 error when posting valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet reopened COUCHDB-3431:
--
> 400 error when posting valid JSON
> -
>
> Key: COUCHDB-3431
> URL: https://issues.apache.org/jira/browse/COUCHDB-3431
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: glen
>
> Is anything invalid about the first member of an array being an empty object?
> Please post [{}] to your Couch. Does your Couch return invalid json 400
> error, or is it just me?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3431) 400 error when posting valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3431.
Resolution: Invalid
CouchDB is a document-oriented database, not an array-oriented database. As
such, we require the top-level structure to be an object, not an array.
This is because, at the very least, we have to place an "_id":"" in the
object to act as the "primary key" via which to access the document itself. We
couldn't do this if the top-level is an array.
> 400 error when posting valid JSON
> -
>
> Key: COUCHDB-3431
> URL: https://issues.apache.org/jira/browse/COUCHDB-3431
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: glen
>
> Is anything invalid about the first member of an array being an empty object?
> Please post [{}] to your Couch. Does your Couch return invalid json 400
> error, or is it just me?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3431) 400 error when posting valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3431.
Resolution: Fixed
It's whatever you're doing for encoding that is wrong. It definitely works.
$ curl -X PUT localhost:15984/foo
{"ok":true}
$ curl -X PUT localhost:15984/foo/bar -d '{"array":[{}]}'
{"ok":true,"id":"bar","rev":"1-3ff089b81196a0ce18d927c093a9b3de"}
$ curl localhost:15984/foo/bar
{"_id":"bar","_rev":"1-3ff089b81196a0ce18d927c093a9b3de","array":[{}]}
> 400 error when posting valid JSON
> -
>
> Key: COUCHDB-3431
> URL: https://issues.apache.org/jira/browse/COUCHDB-3431
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: glen
>
> Is anything invalid about the first member of an array being an empty object?
> Please post [{}] to your Couch. Does your Couch return invalid json 400
> error, or is it just me?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3432) make fails at jiffy
[
https://issues.apache.org/jira/browse/COUCHDB-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3432.
Resolution: Works for Me
> make fails at jiffy
> ---
>
> Key: COUCHDB-3432
> URL: https://issues.apache.org/jira/browse/COUCHDB-3432
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Reporter: Nicholas Chandoke
>
> On CentOS 7. {{[g]make release}} fails:
> {quote}==> couch_epi (compile)
> [. . .]
> ==> ioq (compile)
> ==> jiffy (compile)
> Compiling /home/n/apache-couchdb-2.0.0/src/jiffy/c_src/doubles.cc
> sh: line 0: exec: c++: not found
> ERROR: compile failed while processing
> /home/n/apache-couchdb-2.0.0/src/jiffy: rebar_abort
> gmake: *** [couch] Error 1{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3432) make fails at jiffy
[
https://issues.apache.org/jira/browse/COUCHDB-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078341#comment-16078341
]
Joan Touzet commented on COUCHDB-3432:
--
You are missing a build dependency.
Here is what we install to build on CentOS 7:
https://github.com/apache/couchdb-ci/blob/master/ansible/roles/dependencies-centos/tasks/main.yml
> make fails at jiffy
> ---
>
> Key: COUCHDB-3432
> URL: https://issues.apache.org/jira/browse/COUCHDB-3432
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Reporter: Nicholas Chandoke
>
> On CentOS 7. {{[g]make release}} fails:
> {quote}==> couch_epi (compile)
> [. . .]
> ==> ioq (compile)
> ==> jiffy (compile)
> Compiling /home/n/apache-couchdb-2.0.0/src/jiffy/c_src/doubles.cc
> sh: line 0: exec: c++: not found
> ERROR: compile failed while processing
> /home/n/apache-couchdb-2.0.0/src/jiffy: rebar_abort
> gmake: *** [couch] Error 1{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3170) Permissions are ignored in "_users" database.
[
https://issues.apache.org/jira/browse/COUCHDB-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075103#comment-16075103
]
Joan Touzet commented on COUCHDB-3170:
--
Pretty sure that you have to be an actual server-level admin ([admins] section
in the ini file) for _users once you create a _security object for _users. I
don't believe it is delegatable to non-server admins.
> Permissions are ignored in "_users" database.
> -
>
> Key: COUCHDB-3170
> URL: https://issues.apache.org/jira/browse/COUCHDB-3170
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Pavel V
>
> To reproduce (in Fauxton):
> 1. Create a user in "_users" database with role "app-admin".
> 2. Change permissions for "_users" DB to add "app-admin" role to admins and
> members.
> 3. Check "/_users/_security". Response should be similar to:
> {"admins":{"names":[],"roles":["app-admin"]},"members":{"names":[],"roles":["app-admin"]},"ok":true}
> 4. Login as the user with the "app-admin" role.
> 5. Open "_users", you get 401 response and Fauxton shows message "An Error
> occurred: You are not a server admin.". 401 response contains following JSON:
> {error: "unauthorized", reason: "You are not a server admin."}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COUCHDB-3170) Permissions are ignored in "_users" database.
[
https://issues.apache.org/jira/browse/COUCHDB-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3170.
--
Resolution: Not A Problem
> Permissions are ignored in "_users" database.
> -
>
> Key: COUCHDB-3170
> URL: https://issues.apache.org/jira/browse/COUCHDB-3170
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Pavel V
>
> To reproduce (in Fauxton):
> 1. Create a user in "_users" database with role "app-admin".
> 2. Change permissions for "_users" DB to add "app-admin" role to admins and
> members.
> 3. Check "/_users/_security". Response should be similar to:
> {"admins":{"names":[],"roles":["app-admin"]},"members":{"names":[],"roles":["app-admin"]},"ok":true}
> 4. Login as the user with the "app-admin" role.
> 5. Open "_users", you get 401 response and Fauxton shows message "An Error
> occurred: You are not a server admin.". 401 response contains following JSON:
> {error: "unauthorized", reason: "You are not a server admin."}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3344) EUnit: compaction_daemon_tests timing out
[
https://issues.apache.org/jira/browse/COUCHDB-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3344.
Resolution: Incomplete
Migrated to https://github.com/apache/couchdb/issues/638
> EUnit: compaction_daemon_tests timing out
> -
>
> Key: COUCHDB-3344
> URL: https://issues.apache.org/jira/browse/COUCHDB-3344
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> We thought we'd hammered the compaction daemon tests out, but there's still a
> situation where the test can time out. This has happened at least 4 times
> since Paul Davis checked in his fixes.
> {noformat}
> module 'couchdb_compaction_daemon_tests'
> Compaction daemon tests
> couchdb_compaction_daemon_tests:74:
> should_compact_by_default_rule...*timed out*
> undefined
> couchdb_compaction_daemon_tests:109: should_compact_by_dbname_rule...*timed
> out*
> undefined
> {noformat}
> Sometimes, only one of the tests times out:
> {noformat}
> module 'couchdb_compaction_daemon_tests'
> Compaction daemon tests
> couchdb_compaction_daemon_tests:74:
> should_compact_by_default_rule...*timed out*
> undefined
> couchdb_compaction_daemon_tests:109:
> should_compact_by_dbname_rule...[38.982 s] ok
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3419) EUnit: couchdb_os_proc_pool timeouts
[
https://issues.apache.org/jira/browse/COUCHDB-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072898#comment-16072898
]
Joan Touzet commented on COUCHDB-3419:
--
Moved to https://github.com/apache/couchdb/issues/631
> EUnit: couchdb_os_proc_pool timeouts
>
>
> Key: COUCHDB-3419
> URL: https://issues.apache.org/jira/browse/COUCHDB-3419
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> https://travis-ci.org/apache/couchdb/jobs/232602947#L2781-L2820
> {noformat}
> module 'couchdb_os_proc_pool'
> OS processes pool tests
> couchdb_os_proc_pool:50: should_block_new_proc_on_full_pool...*failed*
> in function
> couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 55)
> in call from
> couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-13-'/0
> (test/couchdb_os_proc_pool.erl, line 55)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,55},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:85:
> should_free_slot_on_proc_unexpected_exit...*failed*
> in function
> couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 90)
> in call from
> couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-19-'/0
> (test/couchdb_os_proc_pool.erl, line 90)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,90},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:126: should_reuse_known_proc...*failed*
> in function couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 130)
> in call from couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-11-'/0
> (test/couchdb_os_proc_pool.erl, line 130)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,130},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:183: should_reduce_pool_on_idle_os_procs...*failed*
> in function
> couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 193)
> in call from
> couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-8-'/0
> (test/couchdb_os_proc_pool.erl, line 193)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,193},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3419) EUnit: couchdb_os_proc_pool timeouts
[
https://issues.apache.org/jira/browse/COUCHDB-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3419.
Resolution: Incomplete
> EUnit: couchdb_os_proc_pool timeouts
>
>
> Key: COUCHDB-3419
> URL: https://issues.apache.org/jira/browse/COUCHDB-3419
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> https://travis-ci.org/apache/couchdb/jobs/232602947#L2781-L2820
> {noformat}
> module 'couchdb_os_proc_pool'
> OS processes pool tests
> couchdb_os_proc_pool:50: should_block_new_proc_on_full_pool...*failed*
> in function
> couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 55)
> in call from
> couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-13-'/0
> (test/couchdb_os_proc_pool.erl, line 55)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,55},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:85:
> should_free_slot_on_proc_unexpected_exit...*failed*
> in function
> couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 90)
> in call from
> couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-19-'/0
> (test/couchdb_os_proc_pool.erl, line 90)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,90},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:126: should_reuse_known_proc...*failed*
> in function couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 130)
> in call from couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-11-'/0
> (test/couchdb_os_proc_pool.erl, line 130)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,130},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:183: should_reduce_pool_on_idle_os_procs...*failed*
> in function
> couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 193)
> in call from
> couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-8-'/0
> (test/couchdb_os_proc_pool.erl, line 193)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,193},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3395) Cannot start CouchDB after first time install
[ https://issues.apache.org/jira/browse/COUCHDB-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-3395. Resolution: Incomplete Fix Version/s: 2.1 This is a duplicate of a ticket in our new tracking system. https://github.com/apache/couchdb/issues/508 > Cannot start CouchDB after first time install > - > > Key: COUCHDB-3395 > URL: https://issues.apache.org/jira/browse/COUCHDB-3395 > Project: CouchDB > Issue Type: Bug > Components: Build System >Affects Versions: 2.0.0 >Reporter: Kun Shao > Fix For: 2.1 > > > OS: > - Windows 10 Version 10.0.15063 Build 15063 > CouchDB Version: > - 2.0.0 binary installation > Observation: > Installation Wizard successful, but localhost:5984/_utils/ does not connect. > When I look at Resource Monitor -> Network, there is no process that is > listening to port 5984. When I look at services.msc, the "Apache CouchDb" > service is paused and cannot be restarted. Trying to restart the service > gives me the following error: > Windows could not start the Apache CouchDB service on Local Computer. The > service did not return an error. This could be an internal Windows error or > an internal service error. If the problem persists, contact your system > administrator. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COUCHDB-3272) CouchDB Cluster: internal server error on database creation
[
https://issues.apache.org/jira/browse/COUCHDB-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053046#comment-16053046
]
Joan Touzet commented on COUCHDB-3272:
--
http://docs.couchdb.org/en/latest/cluster/setup.html has very complete
instructions. You do not need DNS as long as you have accessible IP addresses.
> CouchDB Cluster: internal server error on database creation
>
>
> Key: COUCHDB-3272
> URL: https://issues.apache.org/jira/browse/COUCHDB-3272
> Project: CouchDB
> Issue Type: Question
> Components: Fauxton, Setup
>Reporter: Ganesh Jadhav
>
> I have setup CouchDB cluster with two nodes using the Cluster Setup Api
> (http://docs.couchdb.org/en/latest/cluster/setup.html#the-cluster-setup-api).
> I ran following four commands on both nodes:
>
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "enable_cluster", "bind_address":"xxx.xxx.xxx.xxx", "username": "admin",
> "password":"password"}'
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "enable_cluster", "bind_address":"xxx.xxx.xxx.xxx", "username": "admin",
> "password":"password", "port": 5984, "remote_node": "yyy.yyy.yyy.yyy",
> "remote_current_user": "admin", "remote_current_password": "password" }'
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "add_node", "host":"yyy.yyy.yyy.yyy", "port": "5984", "username": "admin",
> "password":"password"}'
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "finish_cluster"}'
> After doing this I checked node members by follwoing command on one of my
> node:
> http://xxx.xxx.xxx.xxx:5984/_membership
> And got following response
> {"all_nodes":["couchdb@localhost"],"cluster_nodes":["couc...@yyy.yyy.yyy.yyy","couchdb@localhost"]}
> After that when I tried to create new database on one of my node I got
> following error on dashboard:
> "Create database failed: internal_server_error"
> In couchDB log file following log got created:
> [notice] 2017-01-18T07:53:52.884041Z couchdb@localhost 9bb13795a4
> xxx.xxx.xxx.xxx:5984 xxx.xxx.xxx.xxx undefined PUT /testdb 500 ok 247
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COUCHDB-3272) CouchDB Cluster: internal server error on database creation
[
https://issues.apache.org/jira/browse/COUCHDB-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3272.
Resolution: Not A Bug
> CouchDB Cluster: internal server error on database creation
>
>
> Key: COUCHDB-3272
> URL: https://issues.apache.org/jira/browse/COUCHDB-3272
> Project: CouchDB
> Issue Type: Question
> Components: Fauxton, Setup
>Reporter: Ganesh Jadhav
>
> I have setup CouchDB cluster with two nodes using the Cluster Setup Api
> (http://docs.couchdb.org/en/latest/cluster/setup.html#the-cluster-setup-api).
> I ran following four commands on both nodes:
>
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "enable_cluster", "bind_address":"xxx.xxx.xxx.xxx", "username": "admin",
> "password":"password"}'
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "enable_cluster", "bind_address":"xxx.xxx.xxx.xxx", "username": "admin",
> "password":"password", "port": 5984, "remote_node": "yyy.yyy.yyy.yyy",
> "remote_current_user": "admin", "remote_current_password": "password" }'
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "add_node", "host":"yyy.yyy.yyy.yyy", "port": "5984", "username": "admin",
> "password":"password"}'
> curl -X POST -H "Content-Type: application/json"
> http://admin:passw...@xxx.xxx.xxx.xxx:5984/_cluster_setup -d '{"action":
> "finish_cluster"}'
> After doing this I checked node members by follwoing command on one of my
> node:
> http://xxx.xxx.xxx.xxx:5984/_membership
> And got following response
> {"all_nodes":["couchdb@localhost"],"cluster_nodes":["couc...@yyy.yyy.yyy.yyy","couchdb@localhost"]}
> After that when I tried to create new database on one of my node I got
> following error on dashboard:
> "Create database failed: internal_server_error"
> In couchDB log file following log got created:
> [notice] 2017-01-18T07:53:52.884041Z couchdb@localhost 9bb13795a4
> xxx.xxx.xxx.xxx:5984 xxx.xxx.xxx.xxx undefined PUT /testdb 500 ok 247
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COUCHDB-3172) httpd_global_handlers proxy on main cluster interface
[
https://issues.apache.org/jira/browse/COUCHDB-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16042256#comment-16042256
]
Joan Touzet commented on COUCHDB-3172:
--
There are plans to improve the integration of clouseau/dreyfus (and the Geo
addon, hastings/easton) to make them integrate without recompilation, but
probably not until 3.0.
I'm not closing this issue because you're right, it's still broken. Clustering
makes things more complex, since you need the service running on every node in
a cluster. I'm not sure how easily this can be done right now.
An easier approach might be to configure a new backend in the front-end load
balancer (such as haproxy, which is very commonly used in CouchDB cluster
deployments). This can do pattern-matching on the request URL and forward the
request to the appropriate backend, regardless of IP address or port.
> httpd_global_handlers proxy on main cluster interface
> -
>
> Key: COUCHDB-3172
> URL: https://issues.apache.org/jira/browse/COUCHDB-3172
> Project: CouchDB
> Issue Type: Bug
>Reporter: Wiktor Obrębski
>
> couch_httpd_proxy looks like no working in main cluster 5984 interface in
> CouchDB 2.0.
> {code:title=config}
> [httpd_global_handlers]
> _fti = {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:5985;>>}
> {code}
> it work only when I use direct node port (5986).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (COUCHDB-3341) EUnit: config listener unknown failure
[
https://issues.apache.org/jira/browse/COUCHDB-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3341.
Resolution: Incomplete
Migrated to https://github.com/apache/couchdb/issues/581
> EUnit: config listener unknown failure
> --
>
> Key: COUCHDB-3341
> URL: https://issues.apache.org/jira/browse/COUCHDB-3341
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> One occurrence in our Jenkins builds so far.
> {noformat}
> module 'couch_log_config_listener_test'
> couch_log_config_listener_test: couch_log_config_test_...*failed*
> in function
> couch_log_config_listener_test:'-check_restart_listener/0-fun-2-'/1
> (test/couch_log_config_listener_test.erl, line 38)
> in call from couch_log_config_listener_test:check_restart_listener/0
> (test/couch_log_config_listener_test.erl, line 38)
> **error:{assertEqual,[{module,couch_log_config_listener_test},
> {line,38},
> {expression,"get_handler ( )"},
> {expected,not_found},
> {value,{config_listener,{couch_log_sup,<0.3192.0>}}}]}
> output:<<"">>
> {noformat}
> No clue what's going on here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3341) EUnit: config listener unknown failure
[
https://issues.apache.org/jira/browse/COUCHDB-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038217#comment-16038217
]
Joan Touzet commented on COUCHDB-3341:
--
Just recurred again, am porting to GH Issues.
> EUnit: config listener unknown failure
> --
>
> Key: COUCHDB-3341
> URL: https://issues.apache.org/jira/browse/COUCHDB-3341
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> One occurrence in our Jenkins builds so far.
> {noformat}
> module 'couch_log_config_listener_test'
> couch_log_config_listener_test: couch_log_config_test_...*failed*
> in function
> couch_log_config_listener_test:'-check_restart_listener/0-fun-2-'/1
> (test/couch_log_config_listener_test.erl, line 38)
> in call from couch_log_config_listener_test:check_restart_listener/0
> (test/couch_log_config_listener_test.erl, line 38)
> **error:{assertEqual,[{module,couch_log_config_listener_test},
> {line,38},
> {expression,"get_handler ( )"},
> {expected,not_found},
> {value,{config_listener,{couch_log_sup,<0.3192.0>}}}]}
> output:<<"">>
> {noformat}
> No clue what's going on here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (COUCHDB-3352) JS: couchjs SIGSEGVs
[
https://issues.apache.org/jira/browse/COUCHDB-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3352.
Resolution: Incomplete
Moved to https://github.com/apache/couchdb/issues/551
> JS: couchjs SIGSEGVs
>
>
> Key: COUCHDB-3352
> URL: https://issues.apache.org/jira/browse/COUCHDB-3352
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server, Test Suite
>Reporter: Joan Touzet
>
> Failures typically look like this:
> {noformat}
> test/javascript/tests/reduce_builtin.js
> Error: {exit_status,139}
> Trace back (most recent call first):
>
> 546: test/javascript/couch.js
> CouchError([object Object])
> 509: test/javascript/couch.js
> ([object CouchHTTP])
> 175: test/javascript/couch.js
> ("(function (doc) {emit(doc.keys, [1, 1]);})","_sum",[object Object])
> 159: test/javascript/tests/reduce_builtin.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
>
> fail
> {noformat}
> Have seen this so far on both CentOS 7 and Ubuntu 14.04.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3312) Error on Make Release
[
https://issues.apache.org/jira/browse/COUCHDB-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017859#comment-16017859
]
Joan Touzet commented on COUCHDB-3312:
--
CentOS 6 ships with js-1.7.0. CouchDB dropped support for anything but 1.8.5
with this release.
You can work around this by either uninstalling js-1.7.0 and compiling
SpiderMonkey 1.8.5 yourself, or you can use 3rd party js-1.8.5 packages for
CentOS 6.
> Error on Make Release
> --
>
> Key: COUCHDB-3312
> URL: https://issues.apache.org/jira/browse/COUCHDB-3312
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Reporter: Elioth Rivera
>
> when make ./configure everything it's ok
> but when i run :
> {code:actionscript}
> # make release
> ==> couch_epi (compile)
> ==> config (compile)
> ==> b64url (compile)
> ==> couch_log (compile)
> ==> chttpd (compile)
> ==> couch (compile)
> Compiling
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:44:
> error: ���JS_StrictPropertyStub��� undeclared here (not in a function)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_ctor���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:57:
> warning: implicit declaration of function ���JS_NewObjectForConstructor���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:57:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:63:
> warning: implicit declaration of function ���JS_SET_RVAL���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_open���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:78:
> warning: implicit declaration of function ���JS_THIS_OBJECT���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:78:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:79:
> warning: implicit declaration of function ���JS_ARGV���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:79:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_set_hdr���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:98:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:99:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_send���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:116:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:117:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���base_url���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:147:
> warning: implicit declaration of function ���JS_RVAL���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:147:
> error: lvalue required as unary ���&��� operand
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���evalcx���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:154:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: ���JSCrossCompartmentCall��� undeclared (first use in this function)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: (Each undeclared identifier is reported only once
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: for each function it appears in.)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: ���call��� undeclared (first use in this function)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:177:
> warning: implicit declaration of function ���JS_SetContextThread���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:177:
> warning: implicit declaration of function ���JS_BeginRequest���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:179:
>
[jira] [Resolved] (COUCHDB-3312) Error on Make Release
[
https://issues.apache.org/jira/browse/COUCHDB-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3312.
--
Resolution: Not A Problem
> Error on Make Release
> --
>
> Key: COUCHDB-3312
> URL: https://issues.apache.org/jira/browse/COUCHDB-3312
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Reporter: Elioth Rivera
>
> when make ./configure everything it's ok
> but when i run :
> {code:actionscript}
> # make release
> ==> couch_epi (compile)
> ==> config (compile)
> ==> b64url (compile)
> ==> couch_log (compile)
> ==> chttpd (compile)
> ==> couch (compile)
> Compiling
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:44:
> error: ���JS_StrictPropertyStub��� undeclared here (not in a function)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_ctor���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:57:
> warning: implicit declaration of function ���JS_NewObjectForConstructor���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:57:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:63:
> warning: implicit declaration of function ���JS_SET_RVAL���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_open���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:78:
> warning: implicit declaration of function ���JS_THIS_OBJECT���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:78:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:79:
> warning: implicit declaration of function ���JS_ARGV���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:79:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_set_hdr���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:98:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:99:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���req_send���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:116:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:117:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���base_url���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:147:
> warning: implicit declaration of function ���JS_RVAL���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:147:
> error: lvalue required as unary ���&��� operand
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:
> In function ���evalcx���:
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:154:
> warning: initialization makes pointer from integer without a cast
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: ���JSCrossCompartmentCall��� undeclared (first use in this function)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: (Each undeclared identifier is reported only once
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: for each function it appears in.)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:159:
> error: ���call��� undeclared (first use in this function)
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:177:
> warning: implicit declaration of function ���JS_SetContextThread���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:177:
> warning: implicit declaration of function ���JS_BeginRequest���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:179:
> warning: implicit declaration of function ���JS_GetStringCharsAndLength���
> /btf/TOOLS/npm-registry/apache-couchdb-2.0.0/src/couch/priv/couch_js/main.c:179:
> warning: assignment makes pointer from integer without a cast
>
[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync
[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016782#comment-16016782
]
Joan Touzet commented on COUCHDB-3421:
--
It's worth noting that the cluster can handle this much load but it makes sense
to spread it across all 3 machines. The specific performance limit for any
given node is a combination of many, many factors, and I can't easily give you
a one-size-fits-all answer as to how much it should be able to handle.
At this point I'm unconvinced you're running into an actual bug. I'll keep this
ticket open for a bit longer, but if you're looking for advice on setting up
and configuring CouchDB at scale, there are multiple professional services
organizations that can help you with that - I'm just one volunteer with many
hats to wear.
> mem3 sync shards WARNING at very low message rate, data doesn't sync
>
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Reporter: Scott Kaul
>Priority: Minor
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z couchdb-3@couchdb-3.couchdb <0.309.0>
> mem3_sync shards/2000-3fff/test.1495035040
> couchdb-2@couchdb-2.couchdb {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync
[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016764#comment-16016764
]
Joan Touzet commented on COUCHDB-3421:
--
Are you just benchmarking, or is this indicative of actual load you expect to
see on the system? If this is just for loading a new database, Is there any way
you could use _bulk_docs instead of lots of individual PUTs?
> mem3 sync shards WARNING at very low message rate, data doesn't sync
>
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Reporter: Scott Kaul
>Priority: Minor
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z couchdb-3@couchdb-3.couchdb <0.309.0>
> mem3_sync shards/2000-3fff/test.1495035040
> couchdb-2@couchdb-2.couchdb {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync
[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016498#comment-16016498
]
Joan Touzet commented on COUCHDB-3421:
--
One more question - you mention that you are hitting 800% CPU. Is the system
also building views during this test - for instance, do you have lots of
couchjs proceses running at the same time? Or is it just beam/beam.smp
consuming all the CPU?
> mem3 sync shards WARNING at very low message rate, data doesn't sync
>
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Reporter: Scott Kaul
>Priority: Minor
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z couchdb-3@couchdb-3.couchdb <0.309.0>
> mem3_sync shards/2000-3fff/test.1495035040
> couchdb-2@couchdb-2.couchdb {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync
[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016494#comment-16016494
]
Joan Touzet commented on COUCHDB-3421:
--
HI Scott,
What do you mean by "900 messages a second?" Are you running 3 instances on the
same machine or 3 different machines? Are you load-balancing all requests
across all 3 instances, or are you making all requests against a single
instance? Have you checked iostat or similar to ensure that you're not running
into disk bandwidth limitations of your host(s)?
You can attach your files to this ticket but I'm afraid I don't have time to
look at them right now - I'm just trying to walk you through a few things off
the top of my head.
> mem3 sync shards WARNING at very low message rate, data doesn't sync
>
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Reporter: Scott Kaul
>Priority: Minor
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z couchdb-3@couchdb-3.couchdb <0.309.0>
> mem3_sync shards/2000-3fff/test.1495035040
> couchdb-2@couchdb-2.couchdb {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync
[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014824#comment-16014824
]
Joan Touzet commented on COUCHDB-3421:
--
To clarify, we officially support docker in testing and development
setups...and currently are transitioning to be responsible for the "official"
image on Docker Hub. I don't see anyone in the current team stepping up and
supporting changes to improve performance in production.
Pull requests from eager contributors welcome ;)
> mem3 sync shards WARNING at very low message rate, data doesn't sync
>
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Reporter: Scott Kaul
>Priority: Minor
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z couchdb-3@couchdb-3.couchdb <0.309.0>
> mem3_sync shards/2000-3fff/test.1495035040
> couchdb-2@couchdb-2.couchdb {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync
[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014416#comment-16014416
]
Joan Touzet commented on COUCHDB-3421:
--
Hi Scott,
I see you are using coreos and docker. This is not an officially supported
configuration for CouchDB at this time. My guess is that you are running into
performance limitations inherent in this configuration. Can you test the same
setup, but without using Docker or coreos?
I can guarantee you that many of us have CouchDB in production with loads far
greater than you are testing with and see no problems of this sort.
> mem3 sync shards WARNING at very low message rate, data doesn't sync
>
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Reporter: Scott Kaul
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z couchdb-3@couchdb-3.couchdb <0.309.0>
> mem3_sync shards/2000-3fff/test.1495035040
> couchdb-2@couchdb-2.couchdb {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COUCHDB-3418) _changes returns a single item that says a doc is deleted
[
https://issues.apache.org/jira/browse/COUCHDB-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3418.
--
Resolution: Not A Problem
> _changes returns a single item that says a doc is deleted
> -
>
> Key: COUCHDB-3418
> URL: https://issues.apache.org/jira/browse/COUCHDB-3418
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Paul Kuruvilla
>
> I discovered this while working on maintaining a replica of the npm registry
> (https://replicate.npmjs.com) for Gratipay (https://gratipay.com).
> When I hit the {{/registry/_changes}} endpoint with a filter for {{doc_id =
> 'adam-test'}}, I get back a single change which says that the doc was
> deleted. This looks like a bug, because I'd expect that every 'deleted'
> change would have a corresponding change for when the doc was created.
> (Please correct me if my understanding is wrong)
> Here is a cURL command to replicate the issue:
> {code}
> curl -XPOST -H "Content-Type: application/json"
> https://replicate.npmjs.com/registry/_changes\?limit\=10\\=_doc_ids -d
> '{"doc_ids": ["adam-test"]}'
> {code}
> The output I receive is:
> {code}
> {
> "results": [
> {"seq":1908160,"id":"adam-test","changes":[{"rev":"2-a543a8082c03a641a098fbe39e58afed"}],"deleted":true}
> ],
> "last_seq":1916520
> }
> {code}
> This was the first such occurrence we hit in the ~ 4 million changes that
> we've processed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3418) _changes returns a single item that says a doc is deleted
[
https://issues.apache.org/jira/browse/COUCHDB-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012950#comment-16012950
]
Joan Touzet commented on COUCHDB-3418:
--
Hi Paul,
This is expected. Database compression means that only the most recent revision
required to successfully replicate the database is present. In the case of a
deleted document, that means that only the "tombstone" (document ID + revision
+ "_deleted": true) is retained. This is done so that if the document is
re-created later (with a revision 1 greater than the previous revision) we can
successfully detect that this newer revision isn't, for instance, the original
revision of that document. This is the same for all documents - older revisions
will be cleaned away during database compression.
Example: Doc is created (rev 1), modified 2 times (revs 2 and 3), and deleted
(rev 4). You replicate and only see the rev 4 tombstone. Later, someone else
also replicates, but re-creates a new version of that document (rev 5). You
replicate with that person later and retrieve the newer version of the document
(the re-created rev 5).
Does this make sense?
> _changes returns a single item that says a doc is deleted
> -
>
> Key: COUCHDB-3418
> URL: https://issues.apache.org/jira/browse/COUCHDB-3418
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Paul Kuruvilla
>
> I discovered this while working on maintaining a replica of the npm registry
> (https://replicate.npmjs.com) for Gratipay (https://gratipay.com).
> When I hit the {{/registry/_changes}} endpoint with a filter for {{doc_id =
> 'adam-test'}}, I get back a single change which says that the doc was
> deleted. This looks like a bug, because I'd expect that every 'deleted'
> change would have a corresponding change for when the doc was created.
> (Please correct me if my understanding is wrong)
> Here is a cURL command to replicate the issue:
> {code}
> curl -XPOST -H "Content-Type: application/json"
> https://replicate.npmjs.com/registry/_changes\?limit\=10\\=_doc_ids -d
> '{"doc_ids": ["adam-test"]}'
> {code}
> The output I receive is:
> {code}
> {
> "results": [
> {"seq":1908160,"id":"adam-test","changes":[{"rev":"2-a543a8082c03a641a098fbe39e58afed"}],"deleted":true}
> ],
> "last_seq":1916520
> }
> {code}
> This was the first such occurrence we hit in the ~ 4 million changes that
> we've processed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3369) Using Fauxton with require_valid_user = true
[
https://issues.apache.org/jira/browse/COUCHDB-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012897#comment-16012897
]
Joan Touzet commented on COUCHDB-3369:
--
Hi Wilhelm,
I'm able to get this working just fine with a brand new CouchDB (compiled from
master - there may be a bug in 2.0.0).
Here's the changes I made to local.ini:
{noformat}
[chttpd]
require_valid_user = true
...
[httpd]
WWW-Authenticate = Basic realm="administrator"
...
[admins]
admin = password
{noformat}
I then get a browser pop-up window for login/password for Fauxton. If this
works for you, can you let us know? Thanks!
> Using Fauxton with require_valid_user = true
>
>
> Key: COUCHDB-3369
> URL: https://issues.apache.org/jira/browse/COUCHDB-3369
> Project: CouchDB
> Issue Type: Question
> Components: Fauxton
>Reporter: Wilhelm Uschtrin
>
> How does this work? I don't even get prompted, I just get an immediate
> {"error":"unauthorized","reason":"Authentication required."}. And apparently
> browser don't allow to pass username:password@host in the URL anymore...
> So, is it even possible to use Fauxton with this setting enabled?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3352) JS: couchjs SIGSEGVs
[
https://issues.apache.org/jira/browse/COUCHDB-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012866#comment-16012866
]
Joan Touzet commented on COUCHDB-3352:
--
Your best bet is to pull the Jenkins Docker images and run the tests in them
yourself until you get a segfault. You can do this via (for example, Ubuntu
12.04, Erlang 18.3):
{noformat}
$ docker run -it couchdbdev/ubuntu-12.04-erlang-18.3 bash
build@e5f478cab4b5:/ansible$ ~/build-ci.sh
{noformat}
The full list of images is here:
{{https://github.com/apache/couchdb-ci/tree/master/bin}} Only images with
{{erlang}} in the name are useful.
> JS: couchjs SIGSEGVs
>
>
> Key: COUCHDB-3352
> URL: https://issues.apache.org/jira/browse/COUCHDB-3352
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server, Test Suite
>Reporter: Joan Touzet
>
> Failures typically look like this:
> {noformat}
> test/javascript/tests/reduce_builtin.js
> Error: {exit_status,139}
> Trace back (most recent call first):
>
> 546: test/javascript/couch.js
> CouchError([object Object])
> 509: test/javascript/couch.js
> ([object CouchHTTP])
> 175: test/javascript/couch.js
> ("(function (doc) {emit(doc.keys, [1, 1]);})","_sum",[object Object])
> 159: test/javascript/tests/reduce_builtin.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
>
> fail
> {noformat}
> Have seen this so far on both CentOS 7 and Ubuntu 14.04.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3420) We have a GET query to fetch data from couchDB, ba...
[ https://issues.apache.org/jira/browse/COUCHDB-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012825#comment-16012825 ] Joan Touzet commented on COUCHDB-3420: -- Hi there, you came on IRC and told us this is with an ancient version of CouchDB (1.0.4, which is like 10 years old). We're not going to patch or support this old version. We strongly suggest you upgrade your version of CouchDB. You definitely won't get a 413 response from a newer version with a response that is greater than 4200 characters. I do it every day. > We have a GET query to fetch data from couchDB, ba... > - > > Key: COUCHDB-3420 > URL: https://issues.apache.org/jira/browse/COUCHDB-3420 > Project: CouchDB > Issue Type: Bug >Reporter: ASF subversion and git services > > We have a GET query to fetch data from couchDB, based on criteria, sometimes > it gets longer that 4200 chars (query string, including hostname). > When the query gets longer than 4200 chars, we are not able to fetch data > (even using curl), we get HTTP 413 (Request entity too large) > Strange this is, if we hit the query using Chrome, then anyting longer that > 4080 chars, we get HTTP 413 issue. Also, we have NodeJS server to fetch data, > and we use cradle to connect to couchDB, in this configuration anything > longer that 3400 chars, throws 413 issue. > My question is > 1. What is the exact limit and how to find it? > 2. Why different clients have different limit > PS: in all the cases the error is reported in couch log file, so it is couch > which is throwing this issue and not client. > *Reporter*: Chetan > *E-mail*: [mailto:ctingu...@themix.org] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (COUCHDB-3420) We have a GET query to fetch data from couchDB, ba...
[ https://issues.apache.org/jira/browse/COUCHDB-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-3420. Resolution: Won't Fix > We have a GET query to fetch data from couchDB, ba... > - > > Key: COUCHDB-3420 > URL: https://issues.apache.org/jira/browse/COUCHDB-3420 > Project: CouchDB > Issue Type: Bug >Reporter: ASF subversion and git services > > We have a GET query to fetch data from couchDB, based on criteria, sometimes > it gets longer that 4200 chars (query string, including hostname). > When the query gets longer than 4200 chars, we are not able to fetch data > (even using curl), we get HTTP 413 (Request entity too large) > Strange this is, if we hit the query using Chrome, then anyting longer that > 4080 chars, we get HTTP 413 issue. Also, we have NodeJS server to fetch data, > and we use cradle to connect to couchDB, in this configuration anything > longer that 3400 chars, throws 413 issue. > My question is > 1. What is the exact limit and how to find it? > 2. Why different clients have different limit > PS: in all the cases the error is reported in couch log file, so it is couch > which is throwing this issue and not client. > *Reporter*: Chetan > *E-mail*: [mailto:ctingu...@themix.org] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COUCHDB-3419) EUnit: couchdb_os_proc_pool timeouts
[
https://issues.apache.org/jira/browse/COUCHDB-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011480#comment-16011480
]
Joan Touzet commented on COUCHDB-3419:
--
Log files at
https://couchdb-vm2.apache.org/ci_errorlogs/travis-couchdb-232602947-2017-05-15T21%3A47%3A17.936076/couchlog.tar.gz
> EUnit: couchdb_os_proc_pool timeouts
>
>
> Key: COUCHDB-3419
> URL: https://issues.apache.org/jira/browse/COUCHDB-3419
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> https://travis-ci.org/apache/couchdb/jobs/232602947#L2781-L2820
> {noformat}
> module 'couchdb_os_proc_pool'
> OS processes pool tests
> couchdb_os_proc_pool:50: should_block_new_proc_on_full_pool...*failed*
> in function
> couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 55)
> in call from
> couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-13-'/0
> (test/couchdb_os_proc_pool.erl, line 55)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,55},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:85:
> should_free_slot_on_proc_unexpected_exit...*failed*
> in function
> couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 90)
> in call from
> couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-19-'/0
> (test/couchdb_os_proc_pool.erl, line 90)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,90},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:126: should_reuse_known_proc...*failed*
> in function couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 130)
> in call from couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-11-'/0
> (test/couchdb_os_proc_pool.erl, line 130)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,130},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> couchdb_os_proc_pool:183: should_reduce_pool_on_idle_os_procs...*failed*
> in function
> couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-0-'/2
> (test/couchdb_os_proc_pool.erl, line 193)
> in call from
> couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-8-'/0
> (test/couchdb_os_proc_pool.erl, line 193)
> **error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
> {line,193},
> {expression,"ping_client ( Client1 )"},
> {expected,ok},
> {value,timeout}]}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3419) EUnit: couchdb_os_proc_pool timeouts
Joan Touzet created COUCHDB-3419:
Summary: EUnit: couchdb_os_proc_pool timeouts
Key: COUCHDB-3419
URL: https://issues.apache.org/jira/browse/COUCHDB-3419
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
https://travis-ci.org/apache/couchdb/jobs/232602947#L2781-L2820
{noformat}
module 'couchdb_os_proc_pool'
OS processes pool tests
couchdb_os_proc_pool:50: should_block_new_proc_on_full_pool...*failed*
in function
couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-0-'/2
(test/couchdb_os_proc_pool.erl, line 55)
in call from
couchdb_os_proc_pool:'-should_block_new_proc_on_full_pool/0-fun-13-'/0
(test/couchdb_os_proc_pool.erl, line 55)
**error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
{line,55},
{expression,"ping_client ( Client1 )"},
{expected,ok},
{value,timeout}]}
couchdb_os_proc_pool:85: should_free_slot_on_proc_unexpected_exit...*failed*
in function
couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-0-'/2
(test/couchdb_os_proc_pool.erl, line 90)
in call from
couchdb_os_proc_pool:'-should_free_slot_on_proc_unexpected_exit/0-fun-19-'/0
(test/couchdb_os_proc_pool.erl, line 90)
**error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
{line,90},
{expression,"ping_client ( Client1 )"},
{expected,ok},
{value,timeout}]}
couchdb_os_proc_pool:126: should_reuse_known_proc...*failed*
in function couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-0-'/2
(test/couchdb_os_proc_pool.erl, line 130)
in call from couchdb_os_proc_pool:'-should_reuse_known_proc/0-fun-11-'/0
(test/couchdb_os_proc_pool.erl, line 130)
**error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
{line,130},
{expression,"ping_client ( Client1 )"},
{expected,ok},
{value,timeout}]}
couchdb_os_proc_pool:183: should_reduce_pool_on_idle_os_procs...*failed*
in function
couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-0-'/2
(test/couchdb_os_proc_pool.erl, line 193)
in call from
couchdb_os_proc_pool:'-should_reduce_pool_on_idle_os_procs/0-fun-8-'/0
(test/couchdb_os_proc_pool.erl, line 193)
**error:{assertEqual_failed,[{module,couchdb_os_proc_pool},
{line,193},
{expression,"ping_client ( Client1 )"},
{expected,ok},
{value,timeout}]}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-2596) Debian Package
[ https://issues.apache.org/jira/browse/COUCHDB-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011067#comment-16011067 ] Joan Touzet commented on COUCHDB-2596: -- Believe me we are working those issues - they are simply not being tracked in this bug. > Debian Package > -- > > Key: COUCHDB-2596 > URL: https://issues.apache.org/jira/browse/COUCHDB-2596 > Project: CouchDB > Issue Type: Task > Components: Build System >Reporter: Robert Kowalski >Priority: Minor > Fix For: 2.0.1 > > > Provide an unofficial debian package for 2.0 which will raise adoption -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (COUCHDB-3029) make install - problem - Ubuntu 16.04 Desktop - wrong file version?
[ https://issues.apache.org/jira/browse/COUCHDB-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-3029. Resolution: Fixed This is not a CouchDB issue. > make install - problem - Ubuntu 16.04 Desktop - wrong file version? > --- > > Key: COUCHDB-3029 > URL: https://issues.apache.org/jira/browse/COUCHDB-3029 > Project: CouchDB > Issue Type: Bug > Components: Build System >Reporter: Sinan Gabel > > Hi! > Couchdb 2.0 preview seems to work fine when I do "dev/run". > I get the below error when doing "make install". It seems to have to do with > a wrong file version, namely: "x86_64-linux-gnu-gcov-tool.1.gz" > ... > ==> setup (compile) > ==> rel (compile) > ==> couchdb (compile) > Installing CouchDB into //usr/local/lib/couchdb... > ==> rel (generate) > ERROR: Unable to generate spec: read file info > /usr/lib/erlang/man/man1/x86_64-linux-gnu-gcov-tool.1.gz failed > ERROR: Unexpected error: rebar_abort > ERROR: generate failed while processing /usr/local/src/couchdb/rel: > rebar_abort > Makefile:85: recipe for target 'install' failed > make: *** [install] Error 1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COUCHDB-2596) Debian Package
[ https://issues.apache.org/jira/browse/COUCHDB-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010777#comment-16010777 ] Joan Touzet commented on COUCHDB-2596: -- See https://lists.apache.org/thread.html/9d8030f02e2a4ba1edf73cd4438b740e59026d2f0f2a9b4a325f6909@%3Cuser.couchdb.apache.org%3E for details on the Debian and Ubuntu beta packages. > Debian Package > -- > > Key: COUCHDB-2596 > URL: https://issues.apache.org/jira/browse/COUCHDB-2596 > Project: CouchDB > Issue Type: Task > Components: Build System >Reporter: Robert Kowalski >Priority: Minor > Fix For: 2.0.1 > > > Provide an unofficial debian package for 2.0 which will raise adoption -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (COUCHDB-2596) Debian Package
[ https://issues.apache.org/jira/browse/COUCHDB-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-2596. Resolution: Fixed Done - see the couchdb-ci repository and the user@ mailing list for details. > Debian Package > -- > > Key: COUCHDB-2596 > URL: https://issues.apache.org/jira/browse/COUCHDB-2596 > Project: CouchDB > Issue Type: Task > Components: Build System >Reporter: Robert Kowalski >Priority: Minor > Fix For: 2.0.1 > > > Provide an unofficial debian package for 2.0 which will raise adoption -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (COUCHDB-3354) JS: replicator_db_compact_rep_db failed
[
https://issues.apache.org/jira/browse/COUCHDB-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3354.
Resolution: Invalid
This test was disabled at the time - no clue why it failed. Closing as invalid.
> JS: replicator_db_compact_rep_db failed
> ---
>
> Key: COUCHDB-3354
> URL: https://issues.apache.org/jira/browse/COUCHDB-3354
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> No other information to go on here, unfortunately. Single failure to date.
> {noformat}
> test/javascript/tests/replicator_db_compact_rep_db.js fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3352) JS: couchjs SIGSEGVs
[
https://issues.apache.org/jira/browse/COUCHDB-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003684#comment-16003684
]
Joan Touzet commented on COUCHDB-3352:
--
Still getting this, now in view compaction (Ubuntu 14.04, Erlang 18.3)
{noformat}
test/javascript/tests/view_compaction.js
Error: {exit_status,139}
Trace back (most recent call first):
548: test/javascript/couch.js
CouchError([object Object])
511: test/javascript/couch.js
([object CouchHTTP])
199: test/javascript/couch.js
("foo/view1",[object Object])
72: test/javascript/tests/view_compaction.js
()
37: test/javascript/cli_runner.js
runTest()
48: test/javascript/cli_runner.js
fail
{noformat}
> JS: couchjs SIGSEGVs
>
>
> Key: COUCHDB-3352
> URL: https://issues.apache.org/jira/browse/COUCHDB-3352
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server, Test Suite
>Reporter: Joan Touzet
>
> Failures typically look like this:
> {noformat}
> test/javascript/tests/reduce_builtin.js
> Error: {exit_status,139}
> Trace back (most recent call first):
>
> 546: test/javascript/couch.js
> CouchError([object Object])
> 509: test/javascript/couch.js
> ([object CouchHTTP])
> 175: test/javascript/couch.js
> ("(function (doc) {emit(doc.keys, [1, 1]);})","_sum",[object Object])
> 159: test/javascript/tests/reduce_builtin.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
>
> fail
> {noformat}
> Have seen this so far on both CentOS 7 and Ubuntu 14.04.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COUCHDB-3412) JS: stats.js FAIL restart
[
https://issues.apache.org/jira/browse/COUCHDB-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3412.
--
Resolution: Fixed
Timeout to wait for restart was 5s. Doubled to 10s. Closing for now - will
reopen if issue reappears.
> JS: stats.js FAIL restart
> -
>
> Key: COUCHDB-3412
> URL: https://issues.apache.org/jira/browse/COUCHDB-3412
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> Server restart is failing for some reason.
> {noformat}
> test/javascript/tests/stats.js
> FAIL restart
> fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3412) JS: stats.js FAIL restart
[
https://issues.apache.org/jira/browse/COUCHDB-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003622#comment-16003622
]
Joan Touzet commented on COUCHDB-3412:
--
A third time in Jenkins now. CentOS 6, Erlang 18.3.
> JS: stats.js FAIL restart
> -
>
> Key: COUCHDB-3412
> URL: https://issues.apache.org/jira/browse/COUCHDB-3412
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> Server restart is failing for some reason.
> {noformat}
> test/javascript/tests/stats.js
> FAIL restart
> fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3416) EUnit: couchdb_compaction_daemon_tests fail is_idle check
[
https://issues.apache.org/jira/browse/COUCHDB-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003620#comment-16003620
]
Joan Touzet commented on COUCHDB-3416:
--
A second failure of this type occurred on the same commit, Erlang 18.3 only,
Jenkins, Ubuntu 14.04 (identical OS+Erlang combination). Hm.
> EUnit: couchdb_compaction_daemon_tests fail is_idle check
> -
>
> Key: COUCHDB-3416
> URL: https://issues.apache.org/jira/browse/COUCHDB-3416
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> One failure, Travis, Erlang 18.3.
> {noformat}
> module 'couchdb_compaction_daemon_tests'
> Compaction daemon tests
> couchdb_compaction_daemon_tests:74:
> should_compact_by_default_rule...[25.281 s] ok
> couchdb_compaction_daemon_tests:109:
> should_compact_by_dbname_rule...*failed*
> in function
> couchdb_compaction_daemon_tests:'-should_compact_by_dbname_rule/1-fun-6-'/1
> (test/couchdb_compaction_daemon_tests.erl, line 139)
> in call from
> couchdb_compaction_daemon_tests:'-should_compact_by_dbname_rule/1-fun-7-'/1
> (test/couchdb_compaction_daemon_tests.erl, line 139)
> **error:{assert,[{module,couchdb_compaction_daemon_tests},
> {line,139},
> {expression,"is_idle ( DbName )"},
> {expected,true},
> {value,false}]}
> output:<<"">>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3416) EUnit: couchdb_compaction_daemon_tests fail is_idle check
Joan Touzet created COUCHDB-3416:
Summary: EUnit: couchdb_compaction_daemon_tests fail is_idle check
Key: COUCHDB-3416
URL: https://issues.apache.org/jira/browse/COUCHDB-3416
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
One failure, Travis, Erlang 18.3.
{noformat}
module 'couchdb_compaction_daemon_tests'
Compaction daemon tests
couchdb_compaction_daemon_tests:74:
should_compact_by_default_rule...[25.281 s] ok
couchdb_compaction_daemon_tests:109:
should_compact_by_dbname_rule...*failed*
in function
couchdb_compaction_daemon_tests:'-should_compact_by_dbname_rule/1-fun-6-'/1
(test/couchdb_compaction_daemon_tests.erl, line 139)
in call from
couchdb_compaction_daemon_tests:'-should_compact_by_dbname_rule/1-fun-7-'/1
(test/couchdb_compaction_daemon_tests.erl, line 139)
**error:{assert,[{module,couchdb_compaction_daemon_tests},
{line,139},
{expression,"is_idle ( DbName )"},
{expected,true},
{value,false}]}
output:<<"">>
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COUCHDB-3383) EUnit: couchdb_file_compression_tests timed out
[
https://issues.apache.org/jira/browse/COUCHDB-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3383.
--
Resolution: Fixed
Increased timeout on compression tests to pre-defined TIMEOUT define. Re-open
if this recurs.
> EUnit: couchdb_file_compression_tests timed out
> ---
>
> Key: COUCHDB-3383
> URL: https://issues.apache.org/jira/browse/COUCHDB-3383
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> Ubuntu 16.04, default Erlang version. First time we're seeing this.
> {noformat}
> module 'couchdb_file_compression_tests'
> CouchDB file compression tests
> Use no compression
> couchdb_file_compression_tests:73: should_use_none (compact
> database)...*timed out*
> Use deflate compression at level 1
> couchdb_file_compression_tests:83: should_use_deflate_1 (compact
> database)...[1.576 s] ok
> couchdb_file_compression_tests:84: should_use_deflate_1 (compact
> view)...[0.680 s] ok
> [done in 2.262 s]
> Use deflate compression at level 9
> couchdb_file_compression_tests:93: should_use_deflate_9 (compact
> database)...[1.413 s] ok
> couchdb_file_compression_tests:94: should_use_deflate_9 (compact
> view)...[0.681 s] ok
> [done in 2.100 s]
> Use snappy compression
> couchdb_file_compression_tests:103: should_use_snappy (compact
> database)...[1.096 s] ok
> couchdb_file_compression_tests:104: should_use_snappy (compact
> view)...[0.521 s] ok
> [done in 1.623 s]
> couchdb_file_compression_tests:110: should_compare_compression_methods
> (none > snappy > deflate_1 > deflate_9)...[7.143 s] ok
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3383) EUnit: couchdb_file_compression_tests timed out
[
https://issues.apache.org/jira/browse/COUCHDB-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003521#comment-16003521
]
Joan Touzet commented on COUCHDB-3383:
--
Seen another failure of this variety in Travis today.
{noformat}
module 'couchdb_file_compression_tests'
CouchDB file compression tests
Use no compression
couchdb_file_compression_tests:73: should_use_none (compact
database)...[2.173 s] ok
couchdb_file_compression_tests:74: should_use_none (compact
view)...[0.679 s] ok
[done in 2.858 s]
Use deflate compression at level 1
couchdb_file_compression_tests:83: should_use_deflate_1 (compact
database)...[3.159 s] ok
couchdb_file_compression_tests:84: should_use_deflate_1 (compact
view)...[0.628 s] ok
[done in 3.793 s]
Use deflate compression at level 9
couchdb_file_compression_tests:93: should_use_deflate_9 (compact
database)...[1.873 s] ok
couchdb_file_compression_tests:94: should_use_deflate_9 (compact
view)...[0.841 s] ok
[done in 2.720 s]
Use snappy compression
couchdb_file_compression_tests:103: should_use_snappy (compact
database)...*timed out*
couchdb_file_compression_tests:110: should_compare_compression_methods
(none > snappy > deflate_1 > deflate_9)...[9.278 s] ok
{noformat}
Looks like we need to up the timeout on these tests by a bit.
> EUnit: couchdb_file_compression_tests timed out
> ---
>
> Key: COUCHDB-3383
> URL: https://issues.apache.org/jira/browse/COUCHDB-3383
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> Ubuntu 16.04, default Erlang version. First time we're seeing this.
> {noformat}
> module 'couchdb_file_compression_tests'
> CouchDB file compression tests
> Use no compression
> couchdb_file_compression_tests:73: should_use_none (compact
> database)...*timed out*
> Use deflate compression at level 1
> couchdb_file_compression_tests:83: should_use_deflate_1 (compact
> database)...[1.576 s] ok
> couchdb_file_compression_tests:84: should_use_deflate_1 (compact
> view)...[0.680 s] ok
> [done in 2.262 s]
> Use deflate compression at level 9
> couchdb_file_compression_tests:93: should_use_deflate_9 (compact
> database)...[1.413 s] ok
> couchdb_file_compression_tests:94: should_use_deflate_9 (compact
> view)...[0.681 s] ok
> [done in 2.100 s]
> Use snappy compression
> couchdb_file_compression_tests:103: should_use_snappy (compact
> database)...[1.096 s] ok
> couchdb_file_compression_tests:104: should_use_snappy (compact
> view)...[0.521 s] ok
> [done in 1.623 s]
> couchdb_file_compression_tests:110: should_compare_compression_methods
> (none > snappy > deflate_1 > deflate_9)...[7.143 s] ok
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3415) EUnit: should_accept_live_as_an_alias_for_continuous invalid_trailing_data
Joan Touzet created COUCHDB-3415:
Summary: EUnit: should_accept_live_as_an_alias_for_continuous
invalid_trailing_data
Key: COUCHDB-3415
URL: https://issues.apache.org/jira/browse/COUCHDB-3415
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
New bug. Seen once in Travis, Erlang 17.5. Re-running caused the error to
disappear.
{noformat}
module 'chttpd_db_test'
chttpd db tests
chttpd_db_test:71: should_return_ok_true_on_bulk_update...[0.073 s] ok
chttpd_db_test:86: should_accept_live_as_an_alias_for_continuous...*failed*
in function couch_util:json_decode/1 (src/couch_util.erl, line 414)
in call from
chttpd_db_test:'-should_accept_live_as_an_alias_for_continuous/1-fun-1-'/1
(test/chttpd_db_test.erl, line 98)
**throw:{invalid_json,{error,{257,invalid_trailing_data}}}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-1946) Trying to replicate NPM grinds to a halt after 40GB
[ https://issues.apache.org/jira/browse/COUCHDB-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001952#comment-16001952 ] Joan Touzet commented on COUCHDB-1946: -- I know it's a bit late, but since this issue still seems to occur, I have a PR open with [~kocolosk]'s hibernate tweak against 2.0.0: https://github.com/apache/couchdb/pull/510 > Trying to replicate NPM grinds to a halt after 40GB > --- > > Key: COUCHDB-1946 > URL: https://issues.apache.org/jira/browse/COUCHDB-1946 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Marc Trudel >Priority: Critical > Attachments: couch.log > > > I have been able to replicate the Node.js NPM database until 40G or so, then > I get this: > https://gist.github.com/stelcheck/7723362 > I one case I have gotten a flat-out OOM error, but I didn't take a dump of > the log output at the time. > CentOS6.4 with CouchDB 1.5 (also tried 1.3.1, but to no avail). Also tried to > restart replication from scratch - twice - bot cases stalling at 40GB. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (COUCHDB-3412) JS: stats.js FAIL restart
Joan Touzet created COUCHDB-3412:
Summary: JS: stats.js FAIL restart
Key: COUCHDB-3412
URL: https://issues.apache.org/jira/browse/COUCHDB-3412
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
Server restart is failing for some reason.
{noformat}
test/javascript/tests/stats.js
FAIL restart
fail
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3413) EUnit: test setup fail, db not created
Joan Touzet created COUCHDB-3413:
Summary: EUnit: test setup fail, db not created
Key: COUCHDB-3413
URL: https://issues.apache.org/jira/browse/COUCHDB-3413
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
1 instance so far, in Jenkins. Looks like a database isn't getting created
correctly.
{noformat}
module 'chttpd_db_doc_size_tests'
chttpd db max_document_size tests
chttpd_db_doc_size_tests:72: post_single_doc...[0.007 s] ok
undefined
*** context setup failed ***
**in function chttpd_db_doc_size_tests:'-create_db/1-fun-0-'/1
(test/chttpd_db_doc_size_tests.erl, line 45)
in call from chttpd_db_doc_size_tests:setup/0
(test/chttpd_db_doc_size_tests.erl, line 35)
**error:{assert,[{module,chttpd_db_doc_size_tests},
{line,45},
{expression,"Status =:= 201 orelse Status =:= 202"},
{expected,true},
{value,false}]}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3412) JS: stats.js FAIL restart
[
https://issues.apache.org/jira/browse/COUCHDB-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1657#comment-1657
]
Joan Touzet commented on COUCHDB-3412:
--
Has happened twice in Jenkins only.
> JS: stats.js FAIL restart
> -
>
> Key: COUCHDB-3412
> URL: https://issues.apache.org/jira/browse/COUCHDB-3412
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> Server restart is failing for some reason.
> {noformat}
> test/javascript/tests/stats.js
> FAIL restart
> fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3352) JS: couchjs SIGSEGVs
[
https://issues.apache.org/jira/browse/COUCHDB-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1648#comment-1648
]
Joan Touzet commented on COUCHDB-3352:
--
Back in reduce.js again.
> JS: couchjs SIGSEGVs
>
>
> Key: COUCHDB-3352
> URL: https://issues.apache.org/jira/browse/COUCHDB-3352
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server, Test Suite
>Reporter: Joan Touzet
>
> Failures typically look like this:
> {noformat}
> test/javascript/tests/reduce_builtin.js
> Error: {exit_status,139}
> Trace back (most recent call first):
>
> 546: test/javascript/couch.js
> CouchError([object Object])
> 509: test/javascript/couch.js
> ([object CouchHTTP])
> 175: test/javascript/couch.js
> ("(function (doc) {emit(doc.keys, [1, 1]);})","_sum",[object Object])
> 159: test/javascript/tests/reduce_builtin.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
>
> fail
> {noformat}
> Have seen this so far on both CentOS 7 and Ubuntu 14.04.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3344) EUnit: compaction_daemon_tests timing out
[
https://issues.apache.org/jira/browse/COUCHDB-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1645#comment-1645
]
Joan Touzet commented on COUCHDB-3344:
--
And again.
> EUnit: compaction_daemon_tests timing out
> -
>
> Key: COUCHDB-3344
> URL: https://issues.apache.org/jira/browse/COUCHDB-3344
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> We thought we'd hammered the compaction daemon tests out, but there's still a
> situation where the test can time out. This has happened at least 4 times
> since Paul Davis checked in his fixes.
> {noformat}
> module 'couchdb_compaction_daemon_tests'
> Compaction daemon tests
> couchdb_compaction_daemon_tests:74:
> should_compact_by_default_rule...*timed out*
> undefined
> couchdb_compaction_daemon_tests:109: should_compact_by_dbname_rule...*timed
> out*
> undefined
> {noformat}
> Sometimes, only one of the tests times out:
> {noformat}
> module 'couchdb_compaction_daemon_tests'
> Compaction daemon tests
> couchdb_compaction_daemon_tests:74:
> should_compact_by_default_rule...*timed out*
> undefined
> couchdb_compaction_daemon_tests:109:
> should_compact_by_dbname_rule...[38.982 s] ok
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3342) JS: design_docs expected '"ok"', got '"ko"'
[
https://issues.apache.org/jira/browse/COUCHDB-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1643#comment-1643
]
Joan Touzet commented on COUCHDB-3342:
--
Another instance of this in Travis.
> JS: design_docs expected '"ok"', got '"ko"'
> ---
>
> Key: COUCHDB-3342
> URL: https://issues.apache.org/jira/browse/COUCHDB-3342
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> Seen this 3 times now in the Jenkins CI runs.
> {noformat}
> test/javascript/tests/design_docs.js
> Error: expected '"ok"', got '"ko"'
> Trace back (most recent call first):
> 52: test/javascript/test_setup.js
> T(false,"expected '\"ok\"', got '\"ko\"'",(void 0))
> 321: test/javascript/couch_test_runner.js
> TEquals("ok","ko")
> 222: test/javascript/tests/design_docs.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
> fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3341) EUnit: config listener unknown failure
[
https://issues.apache.org/jira/browse/COUCHDB-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1638#comment-1638
]
Joan Touzet commented on COUCHDB-3341:
--
[~iilyak] git blame says this is your most recent change. Can you look into why
the assert on line 38 couch_log_config_listener_test.erl is failing about once
every 10-20 runs? Thanks.
> EUnit: config listener unknown failure
> --
>
> Key: COUCHDB-3341
> URL: https://issues.apache.org/jira/browse/COUCHDB-3341
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> One occurrence in our Jenkins builds so far.
> {noformat}
> module 'couch_log_config_listener_test'
> couch_log_config_listener_test: couch_log_config_test_...*failed*
> in function
> couch_log_config_listener_test:'-check_restart_listener/0-fun-2-'/1
> (test/couch_log_config_listener_test.erl, line 38)
> in call from couch_log_config_listener_test:check_restart_listener/0
> (test/couch_log_config_listener_test.erl, line 38)
> **error:{assertEqual,[{module,couch_log_config_listener_test},
> {line,38},
> {expression,"get_handler ( )"},
> {expected,not_found},
> {value,{config_listener,{couch_log_sup,<0.3192.0>}}}]}
> output:<<"">>
> {noformat}
> No clue what's going on here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3341) EUnit: config listener unknown failure
[
https://issues.apache.org/jira/browse/COUCHDB-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1632#comment-1632
]
Joan Touzet commented on COUCHDB-3341:
--
Happened again in Jenkins, 14.04, 18.3.
> EUnit: config listener unknown failure
> --
>
> Key: COUCHDB-3341
> URL: https://issues.apache.org/jira/browse/COUCHDB-3341
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> One occurrence in our Jenkins builds so far.
> {noformat}
> module 'couch_log_config_listener_test'
> couch_log_config_listener_test: couch_log_config_test_...*failed*
> in function
> couch_log_config_listener_test:'-check_restart_listener/0-fun-2-'/1
> (test/couch_log_config_listener_test.erl, line 38)
> in call from couch_log_config_listener_test:check_restart_listener/0
> (test/couch_log_config_listener_test.erl, line 38)
> **error:{assertEqual,[{module,couch_log_config_listener_test},
> {line,38},
> {expression,"get_handler ( )"},
> {expected,not_found},
> {value,{config_listener,{couch_log_sup,<0.3192.0>}}}]}
> output:<<"">>
> {noformat}
> No clue what's going on here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3409) CouchDB has intermittent 30sec delays
[
https://issues.apache.org/jira/browse/COUCHDB-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995987#comment-15995987
]
Joan Touzet commented on COUCHDB-3409:
--
If you're running on a Mac, you might be running into this problem:
https://github.com/docker/for-mac/issues/668#issuecomment-248032494
and can use this workaround:
https://gist.github.com/mkrakauer-rio/e7d9de75f5ac680e790365748ca188a4
If you're on a Linux host, I'd like to see results of you trying the same
thing, but running CouchDB in the host (outside of docker).
> CouchDB has intermittent 30sec delays
> -
>
> Key: COUCHDB-3409
> URL: https://issues.apache.org/jira/browse/COUCHDB-3409
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Chris Elder
>
> CouchDB has intermittent 30 delays processing requests when CouchDB is
> installed in a docker image. This occurs for PUT, POST and GET operations.
> The following is a shell script used to replicate the error:
> (the database insert_test was created manually)
> Problem usually occurs after 100 to 300 inserts during testing.
> --
> #!/bin/bash
> for i in {1..500}
> do
> echo "Test insert $i"
> curl -H 'Content-Type: application/json' \
> -X POST http://127.0.0.1:15984/insert_test \
> -d '{"name": "marble"}'
> done
> --
> The following is an extract of the log showing a 30 second delay on a POST
> operation.
> [notice] 2017-05-03T20:46:29.549696Z nonode@nohost <0.17192.22> de7d93ef52
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 4
> [notice] 2017-05-03T20:47:00.397842Z nonode@nohost <0.17198.22> 8d31c7ad19
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 30838
> [notice] 2017-05-03T20:47:00.414558Z nonode@nohost <0.17808.22> f75a66f6cb
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 3
> [notice] 2017-05-03T20:47:00.437651Z nonode@nohost <0.17809.22> 0c53e2bbcf
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 13
> The following is the default.ini used:
> ---
> ; CouchDB Configuration Settings
> ; Custom settings should be made in this file. They will override settings
> ; in default.ini, but unlike changes made to default.ini, this file won't be
> ; overwritten on server upgrade.
> [chttpd]
> bind_address = 0.0.0.0
> [couchdb]
> ; Specify the location of the database in container.
> ; Optionally, these directories can be mounted in the host via docker.
> database_dir = /opt/couchdb/data/
> view_index_dir = /opt/couchdb/data/
> uri_file = /opt/couchdb/data/couch.uri
> ; only allow the admin user to connect
> ; Uncomment the following statement to enable admin user security.
> ; default_security = admin_only
> ; allow delayed commits since peer manages savepoints and flushing to disk
> delayed_commits = true
> [cluster]
> ; peer maintains a single replica
> n = 1
> ; adjust q to set the level of parallelism locally
> ; recommended to have no more than 10 million documents/shard (q)
> ; for 100 million documents, q=10 -- at a minimum
> q = 8
> [log]
> writer = file
> file = /opt/couchdb/logs/couchdb.log
> level = info
> ; Uncomment the following two statements to enable admin user security.
> ; [httpd]
> ; www-authenticate = Basic realm="administrator"
> [couch_httpd_auth]
> ; Uncomment the following statement to enable admin user security.
> ; require_valid_user = true
> iterations = 1000 ; iterations for password hashing
> ; Uncomment the following two statements to enable admin user security.
> ; [admins]
> ; admin = admin
> [attachments]
> compressible_types = text/*, application/javascript, application/json,
> application/xml, application/octet-stream
> ---
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3409) CouchDB has intermittent 30sec delays
[
https://issues.apache.org/jira/browse/COUCHDB-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995968#comment-15995968
]
Joan Touzet commented on COUCHDB-3409:
--
Further info: We run all of our regression tests (Travis and Jenkins) inside of
Docker images, and have never seen this problem in those settings (where a 30
second delay would trigger a timeout in our test harness). I'm betting this is
something specific to your configuration, perhaps specific to the filesystem
storage you're using for the couchdb data directory.
> CouchDB has intermittent 30sec delays
> -
>
> Key: COUCHDB-3409
> URL: https://issues.apache.org/jira/browse/COUCHDB-3409
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Chris Elder
>
> CouchDB has intermittent 30 delays processing requests when CouchDB is
> installed in a docker image. This occurs for PUT, POST and GET operations.
> The following is a shell script used to replicate the error:
> (the database insert_test was created manually)
> Problem usually occurs after 100 to 300 inserts during testing.
> --
> #!/bin/bash
> for i in {1..500}
> do
> echo "Test insert $i"
> curl -H 'Content-Type: application/json' \
> -X POST http://127.0.0.1:15984/insert_test \
> -d '{"name": "marble"}'
> done
> --
> The following is an extract of the log showing a 30 second delay on a POST
> operation.
> [notice] 2017-05-03T20:46:29.549696Z nonode@nohost <0.17192.22> de7d93ef52
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 4
> [notice] 2017-05-03T20:47:00.397842Z nonode@nohost <0.17198.22> 8d31c7ad19
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 30838
> [notice] 2017-05-03T20:47:00.414558Z nonode@nohost <0.17808.22> f75a66f6cb
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 3
> [notice] 2017-05-03T20:47:00.437651Z nonode@nohost <0.17809.22> 0c53e2bbcf
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 13
> The following is the default.ini used:
> ---
> ; CouchDB Configuration Settings
> ; Custom settings should be made in this file. They will override settings
> ; in default.ini, but unlike changes made to default.ini, this file won't be
> ; overwritten on server upgrade.
> [chttpd]
> bind_address = 0.0.0.0
> [couchdb]
> ; Specify the location of the database in container.
> ; Optionally, these directories can be mounted in the host via docker.
> database_dir = /opt/couchdb/data/
> view_index_dir = /opt/couchdb/data/
> uri_file = /opt/couchdb/data/couch.uri
> ; only allow the admin user to connect
> ; Uncomment the following statement to enable admin user security.
> ; default_security = admin_only
> ; allow delayed commits since peer manages savepoints and flushing to disk
> delayed_commits = true
> [cluster]
> ; peer maintains a single replica
> n = 1
> ; adjust q to set the level of parallelism locally
> ; recommended to have no more than 10 million documents/shard (q)
> ; for 100 million documents, q=10 -- at a minimum
> q = 8
> [log]
> writer = file
> file = /opt/couchdb/logs/couchdb.log
> level = info
> ; Uncomment the following two statements to enable admin user security.
> ; [httpd]
> ; www-authenticate = Basic realm="administrator"
> [couch_httpd_auth]
> ; Uncomment the following statement to enable admin user security.
> ; require_valid_user = true
> iterations = 1000 ; iterations for password hashing
> ; Uncomment the following two statements to enable admin user security.
> ; [admins]
> ; admin = admin
> [attachments]
> compressible_types = text/*, application/javascript, application/json,
> application/xml, application/octet-stream
> ---
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3409) CouchDB has intermittent 30sec delays
[
https://issues.apache.org/jira/browse/COUCHDB-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995964#comment-15995964
]
Joan Touzet commented on COUCHDB-3409:
--
I've never seen this. Can you reproduce this problem outside of a Docker
setting? This points to a Docker bug, not a CouchDB one.
> CouchDB has intermittent 30sec delays
> -
>
> Key: COUCHDB-3409
> URL: https://issues.apache.org/jira/browse/COUCHDB-3409
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Chris Elder
>
> CouchDB has intermittent 30 delays processing requests when CouchDB is
> installed in a docker image. This occurs for PUT, POST and GET operations.
> The following is a shell script used to replicate the error:
> (the database insert_test was created manually)
> Problem usually occurs after 100 to 300 inserts during testing.
> --
> #!/bin/bash
> for i in {1..500}
> do
> echo "Test insert $i"
> curl -H 'Content-Type: application/json' \
> -X POST http://127.0.0.1:15984/insert_test \
> -d '{"name": "marble"}'
> done
> --
> The following is an extract of the log showing a 30 second delay on a POST
> operation.
> [notice] 2017-05-03T20:46:29.549696Z nonode@nohost <0.17192.22> de7d93ef52
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 4
> [notice] 2017-05-03T20:47:00.397842Z nonode@nohost <0.17198.22> 8d31c7ad19
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 30838
> [notice] 2017-05-03T20:47:00.414558Z nonode@nohost <0.17808.22> f75a66f6cb
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 3
> [notice] 2017-05-03T20:47:00.437651Z nonode@nohost <0.17809.22> 0c53e2bbcf
> 127.0.0.1:15984 10.0.2.2 undefined POST /connecttest 201 ok 13
> The following is the default.ini used:
> ---
> ; CouchDB Configuration Settings
> ; Custom settings should be made in this file. They will override settings
> ; in default.ini, but unlike changes made to default.ini, this file won't be
> ; overwritten on server upgrade.
> [chttpd]
> bind_address = 0.0.0.0
> [couchdb]
> ; Specify the location of the database in container.
> ; Optionally, these directories can be mounted in the host via docker.
> database_dir = /opt/couchdb/data/
> view_index_dir = /opt/couchdb/data/
> uri_file = /opt/couchdb/data/couch.uri
> ; only allow the admin user to connect
> ; Uncomment the following statement to enable admin user security.
> ; default_security = admin_only
> ; allow delayed commits since peer manages savepoints and flushing to disk
> delayed_commits = true
> [cluster]
> ; peer maintains a single replica
> n = 1
> ; adjust q to set the level of parallelism locally
> ; recommended to have no more than 10 million documents/shard (q)
> ; for 100 million documents, q=10 -- at a minimum
> q = 8
> [log]
> writer = file
> file = /opt/couchdb/logs/couchdb.log
> level = info
> ; Uncomment the following two statements to enable admin user security.
> ; [httpd]
> ; www-authenticate = Basic realm="administrator"
> [couch_httpd_auth]
> ; Uncomment the following statement to enable admin user security.
> ; require_valid_user = true
> iterations = 1000 ; iterations for password hashing
> ; Uncomment the following two statements to enable admin user security.
> ; [admins]
> ; admin = admin
> [attachments]
> compressible_types = text/*, application/javascript, application/json,
> application/xml, application/octet-stream
> ---
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (COUCHDB-2077) Donate and use global_changes
[ https://issues.apache.org/jira/browse/COUCHDB-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-2077. Resolution: Fixed We have _global_changes! Thanks, Cloudant! > Donate and use global_changes > - > > Key: COUCHDB-2077 > URL: https://issues.apache.org/jira/browse/COUCHDB-2077 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Paul Joseph Davis > Labels: release > > global_changes is the clustered version of _db_updates. We need to open > source and donate this code back to Apache. API-wise its equivalent to > _db_updates but persists the updates to disk so that clients can reconnect > and receive notifications that were missed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (COUCHDB-3408) EUnit: couch_replicator_small_max_request_size_target should_replicate timed out
Joan Touzet created COUCHDB-3408:
Summary: EUnit: couch_replicator_small_max_request_size_target
should_replicate timed out
Key: COUCHDB-3408
URL: https://issues.apache.org/jira/browse/COUCHDB-3408
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
Very little to go on.
{noformat}
couch_replicator_small_max_request_size_target:124:
should_replicate...*timed out*
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3343) JS: show_documents failure
[
https://issues.apache.org/jira/browse/COUCHDB-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993483#comment-15993483
]
Joan Touzet commented on COUCHDB-3343:
--
Still getting lots of these on Travis.
> JS: show_documents failure
> --
>
> Key: COUCHDB-3343
> URL: https://issues.apache.org/jira/browse/COUCHDB-3343
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> Has occurred once so far in Jenkins CI runs.
> {noformat}
> test/javascript/tests/show_documents.js
> Error: changed ddoc
> Trace back (most recent call first):
> 52: test/javascript/test_setup.js
> T(false,"changed ddoc")
> 296: test/javascript/tests/show_documents.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
>
> fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3402.
Resolution: Fixed
After patching, I ran startup/shutdown in a loop 30x and was unable to
reproduce (used to occur every 3-4 startups on my machine). Closing.
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Critical
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3407) Prevision version of document button
[ https://issues.apache.org/jira/browse/COUCHDB-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992321#comment-15992321 ] Joan Touzet commented on COUCHDB-3407: -- Hi Sergey, Fauxton issues have moved to GitHub issues. Please re-file your issue here: https://github.com/apache/couchdb-fauxton/issues Thanks! > Prevision version of document button > > > Key: COUCHDB-3407 > URL: https://issues.apache.org/jira/browse/COUCHDB-3407 > Project: CouchDB > Issue Type: Wish > Components: Fauxton >Reporter: Sergey Safarov > > in couchdb 1.6 exist prevision version of document button. > Could you please add similar to latest fauxton -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (COUCHDB-3244) Replication is broken when database name has "/" and cluster is configured
[
https://issues.apache.org/jira/browse/COUCHDB-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3244.
Resolution: Fixed
> Replication is broken when database name has "/" and cluster is configured
> --
>
> Key: COUCHDB-3244
> URL: https://issues.apache.org/jira/browse/COUCHDB-3244
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Sergey Safarov
>
> When CouchDB host is configured as standalone server when i can execute
> command
> curl -s -S -X POST http://127.0.0.1:5984/_replicate -H 'Content-Type:
> application/json' -H 'Accept: application/json, text/javascript'
> --data-binary
> '{"source":"http://xxx.xxx.xxx.xxx:5984/account%2f32%2fc2%2f83a70fb3146e584c4743c557b1df","target":"account/32/c2/83a70fb3146e584c4743c557b1df","continuous":false,"create_target":true}'
> And then get responce like
> {"ok":true,"session_id":"a25fa8ed55c970f3ec6dc7e3f641d515","source_last_seq":"424-g1LzeJyt0DsKwkAQBuDFCAqeQBu9gGGziTGdEU9hpbMvYtwklY2N3kRvojfRm8R9BOxESJoZGGY-hl8hhIaZx9GEVSeWcZoe4TzHga8qBopXBRxKpXd6gOi0rus88yAp9GDAAYdEyp-X_8B0pitdNbZv7SiUEkC0t1Nj7xp7Y20COIIA2tt7Y18ae2xtDAJosGxtl31d0VU3zd-Mv3a5sDgRZNGRf3f-w_hb978QnErWkf90_uv7fywII4x25L-db_MfuXyA8ZD_zj__ADLK8AQ","replication_id_version":3,"history":[{"session_id":"a25fa8ed55c970f3ec6dc7e3f641d515","start_time":"Sat,
> 26 Nov 2016 13:51:02 GMT","end_time":"Sat, 26 Nov 2016 13:51:25
> GMT","start_last_seq":0,"end_last_seq":"424-g1LzeJyt0DsKwkAQBuDFCAqeQBu9gGGziTGdEU9hpbMvYtwklY2N3kRvojfRm8R9BOxESJoZGGY-hl8hhIaZx9GEVSeWcZoe4TzHga8qBopXBRxKpXd6gOi0rus88yAp9GDAAYdEyp-X_8B0pitdNbZv7SiUEkC0t1Nj7xp7Y20COIIA2tt7Y18ae2xtDAJosGxtl31d0VU3zd-Mv3a5sDgRZNGRf3f-w_hb978QnErWkf90_uv7fywII4x25L-db_MfuXyA8ZD_zj__ADLK8AQ","recorded_seq":"424-g1LzeJyt0DsKwkAQBuDFCAqeQBu9gGGziTGdEU9hpbMvYtwklY2N3kRvojfRm8R9BOxESJoZGGY-hl8hhIaZx9GEVSeWcZoe4TzHga8qBopXBRxKpXd6gOi0rus88yAp9GDAAYdEyp-X_8B0pitdNbZv7SiUEkC0t1Nj7xp7Y20COIIA2tt7Y18ae2xtDAJosGxtl31d0VU3zd-Mv3a5sDgRZNGRf3f-w_hb978QnErWkf90_uv7fywII4x25L-db_MfuXyA8ZD_zj__ADLK8AQ","missing_checked":106,"missing_found":106,"docs_read":106,"docs_written":106,"doc_write_failures":0}]}
> But if CouchDB node is joined to cluster same command cannot be executed.
> CouchDB not retrun any responce
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3406) EUnit: should_ensure_replication_still_running failed
Joan Touzet created COUCHDB-3406:
Summary: EUnit: should_ensure_replication_still_running failed
Key: COUCHDB-3406
URL: https://issues.apache.org/jira/browse/COUCHDB-3406
Project: CouchDB
Issue Type: Test
Components: Test Suite
Reporter: Joan Touzet
1 failure so far in couch_replicator_compact_tests. Debian 8, default Erlang.
{noformat}
couch_replicator_compact_tests:98:
should_ensure_replication_still_running...*failed*
in function couch_replicator_compact_tests:check_active_tasks/4
(test/couch_replicator_compact_tests.erl, line 116)
**error:{badmatch,[[{pid,<<"<0.14585.3>">>},
{changes_pending,0},
{checkpoint_interval,3},
{checkpointed_source_seq,0},
{continuous,true},
{database,null},
{doc_id,null},
{doc_write_failures,0},
{docs_read,260},
{docs_written,260},
{missing_revisions_found,260},
{replication_id,<<"3030dd8b"...>>},
{revisions_checked,260},
{source,<<...>>},
{source_seq,...},
{...}|...],
[{pid,<<"<0.23656.3>">>},
{changes_done,1},
{database,<<"eunit-test-db-1493534491315092">>},
{progress,100},
{started_on,1493534520},
{total_changes,1},
{type,database_compaction},
{updated_on,1493534520}]]}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990157#comment-15990157
]
Joan Touzet commented on COUCHDB-3402:
--
https://github.com/apache/couchdb/pull/501 PR issued for this commit.
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Critical
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet reopened COUCHDB-3402:
--
Assignee: Joan Touzet
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Critical
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3405) JS: attachment_ivews gen_server error
Joan Touzet created COUCHDB-3405:
Summary: JS: attachment_ivews gen_server error
Key: COUCHDB-3405
URL: https://issues.apache.org/jira/browse/COUCHDB-3405
Project: CouchDB
Issue Type: Test
Components: Test Suite
Reporter: Joan Touzet
1 failure so far, Jenkins, Ubuntu 16.04.
{noformat}
test/javascript/tests/attachment_views.js
Error: {gen_server,call,[<0.2551.0>,{get_state,8},infinity]}
Trace back (most recent call first):
546: test/javascript/couch.js
CouchError([object Object])
509: test/javascript/couch.js
([object CouchHTTP])
175: test/javascript/couch.js
("(function (doc) {var count = 0;for (var idx in doc._attachments) {co
117: test/javascript/tests/attachment_views.js
()
37: test/javascript/cli_runner.js
runTest()
48: test/javascript/cli_runner.js
fail
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3343) JS: show_documents failure
[
https://issues.apache.org/jira/browse/COUCHDB-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990148#comment-15990148
]
Joan Touzet commented on COUCHDB-3343:
--
Getting a bunch of these on Travis suddenly.
> JS: show_documents failure
> --
>
> Key: COUCHDB-3343
> URL: https://issues.apache.org/jira/browse/COUCHDB-3343
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> Has occurred once so far in Jenkins CI runs.
> {noformat}
> test/javascript/tests/show_documents.js
> Error: changed ddoc
> Trace back (most recent call first):
> 52: test/javascript/test_setup.js
> T(false,"changed ddoc")
> 296: test/javascript/tests/show_documents.js
> ()
> 37: test/javascript/cli_runner.js
> runTest()
> 48: test/javascript/cli_runner.js
>
> fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3396) EUnit: failed_to_start_child
[
https://issues.apache.org/jira/browse/COUCHDB-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990143#comment-15990143
]
Joan Touzet commented on COUCHDB-3396:
--
Another instance of this today, ubuntu 14.04, default Erlang.
> EUnit: failed_to_start_child
>
>
> Key: COUCHDB-3396
> URL: https://issues.apache.org/jira/browse/COUCHDB-3396
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> Multiple failures in chttpd_db_doc_size_tests across multiple platforms.
> {noformat}
> module 'chttpd_db_doc_size_tests'
> chttpd db max_document_size tests
> *** context setup failed ***
> **in function test_util:start_applications/2 (src/test_util.erl, line 91)
> in call from test_util:start_couch/2 (src/test_util.erl, line 74)
> **error:{case_clause,
> {error,
> {{shutdown,
> {failed_to_start_child,couch_secondary_services,
> {shutdown,
> {failed_to_start_child,
>
> "couch_epi_codechange_monitor|chttpd_handlers|providers",
> {noproc,{gen_server,call,...}},
> {couch_app,start,[normal,[]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3402.
--
Resolution: Fixed
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>Priority: Critical
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990122#comment-15990122
]
Joan Touzet commented on COUCHDB-3402:
--
With a little trickery, I managed to get stack traces showing where the
collision happens.
Path 1: {{gen_server:init_it/6 -> mem3_shards:init/1 ->
mem3_shards:get_update_seq/0 -> couch_server:create/2}}
Path 2: {{mem3_sync:initial_sync/1 -> mem3_shards:fold/2 ->
couch_server:create/2}}
It appears that Paths 1 and 2 start nearly simultaneously, with the bug
occurring when Path 2's {{couch_server:create/2}} completes before Path 1's.
This leads to the {{file_exists}} error bubbling back up to
{{mem3_shards:get_update_seq/0}} which doesn't know what to do with it.
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>Priority: Critical
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990110#comment-15990110
]
Joan Touzet commented on COUCHDB-3402:
--
Compare this with a successful startup on the same machine:
{noformat}
[info] 2017-04-30T03:30:03.966197Z node1@127.0.0.1 <0.210.0> Apache
CouchDB has started on http://127.0.0.1:15986/
[info] 2017-04-30T03:30:03.966474Z node1@127.0.0.1 <0.7.0> Application
couch started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:03.966574Z node1@127.0.0.1 <0.7.0> Application
ets_lru started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:03.968188Z node1@127.0.0.1 <0.216.0>
open_result error {not_found,no_db_file} for _nodes
[info] 2017-04-30T03:30:03.968315Z node1@127.0.0.1 <0.7.0> Application
rexi started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.083650Z node1@127.0.0.1 <0.216.0>
open_result error {not_found,no_db_file} for _dbs
[error] 2017-04-30T03:30:04.084361Z node1@127.0.0.1 emulator Error in
process <0.298.0> on node 'node1@127.0.0.1' with exit value:
{{badmatch,file_exists},[{mem3_shards,fold,2,[{file,"src/mem3_shards.erl"},{line,159}]},{mem3_sync,initial_sync,1,[{file,"src/mem3_sync.erl"},{line,241}]}]}
[info] 2017-04-30T03:30:04.143033Z node1@127.0.0.1 <0.7.0> Application
mem3 started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.143250Z node1@127.0.0.1 <0.7.0> Application
fabric started on node 'node1@127.0.0.1'
[error] 2017-04-30T03:30:04.145509Z node1@127.0.0.1 emulator Error in
process <0.337.0> on node 'node1@127.0.0.1' with exit value:
{database_does_not_exist,[{mem3_shards,load_shards_from_db,"_users",[{file,"src/mem3_shards.erl"},{line,397}]},{mem3_shards,load_shards_from_disk,1,[{file,"src/mem3_shards.erl"},{line,372}]},{mem3_shards,load_shards_from_disk...
[notice] 2017-04-30T03:30:04.145701Z node1@127.0.0.1 <0.336.0>
chttpd_auth_cache changes listener died database_does_not_exist at
mem3_shards:load_shards_from_db/6(line:397) <=
mem3_shards:load_shards_from_disk/1(line:372) <=
mem3_shards:load_shards_from_disk/2(line:401) <=
mem3_shards:for_docid/3(line:90) <= fabric_doc_open:go/3(line:38) <=
chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <=
chttpd_auth_cache:listen_for_changes/1(line:134)
[info] 2017-04-30T03:30:04.152381Z node1@127.0.0.1 <0.7.0> Application
chttpd started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.154573Z node1@127.0.0.1 <0.7.0> Application
setup started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.154724Z node1@127.0.0.1 <0.7.0> Application
couch_peruser started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.157003Z node1@127.0.0.1 <0.216.0>
open_result error {not_found,no_db_file} for _replicator
[notice] 2017-04-30T03:30:04.205537Z node1@127.0.0.1 <0.352.0>
creating replicator ddoc <<"_replicator">>
[info] 2017-04-30T03:30:04.265330Z node1@127.0.0.1 <0.7.0> Application
couch_replicator started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.265686Z node1@127.0.0.1 <0.7.0> Application
bear started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.269805Z node1@127.0.0.1 <0.7.0> Application
global_changes started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.269898Z node1@127.0.0.1 <0.7.0> Application
couch_plugins started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.270440Z node1@127.0.0.1 <0.7.0> Application
runtime_tools started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:30:04.271069Z node1@127.0.0.1 <0.7.0> Application
ddoc_cache started on node 'node1@127.0.0.1'
...
{noformat}
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>Priority: Critical
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3402) JS: dev/run timing out starting up nodes
[
https://issues.apache.org/jira/browse/COUCHDB-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990107#comment-15990107
]
Joan Touzet commented on COUCHDB-3402:
--
Lots more instances of this, and I finally got a local reproduce of this one.
We have a crash in mem3:
{noformat}
[info] 2017-04-30T03:16:19.884644Z node1@127.0.0.1 <0.210.0> Apache
CouchDB has started on http://127.0.0.1:15986/
[info] 2017-04-30T03:16:19.884870Z node1@127.0.0.1 <0.7.0> Application
couch started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:16:19.885045Z node1@127.0.0.1 <0.7.0> Application
ets_lru started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:16:19.886104Z node1@127.0.0.1 <0.7.0> Application
rexi started on node 'node1@127.0.0.1'
[info] 2017-04-30T03:16:19.887183Z node1@127.0.0.1 <0.216.0>
open_result error {not_found,no_db_file} for _nodes
[info] 2017-04-30T03:16:20.034961Z node1@127.0.0.1 <0.216.0>
open_result error {not_found,no_db_file} for _dbs
[error] 2017-04-30T03:16:20.036030Z node1@127.0.0.1 <0.283.0>
Supervisor mem3_sup had child mem3_shards started with mem3_shards:start_link()
at undefined exit with reason no match of right hand value file_exists at
mem3_shards:get_update_seq/0(line:318) <= mem3_shards:init/1(line:206) <=
gen_server:init_it/6(line:306) <= proc_lib:init_p_do_apply/3(line:237) in
context start_error
[error] 2017-04-30T03:16:20.036596Z node1@127.0.0.1 <0.298.0> CRASH
REPORT Process (<0.298.0>) with 0 neighbors exited with reason: no match of
right hand value file_exists at mem3_shards:get_update_seq/0(line:318) <=
mem3_shards:init/1(line:206) <= gen_server:init_it/6(line:306) <=
proc_lib:init_p_do_apply/3(line:237) at gen_server:init_it/6(line:330) <=
proc_lib:init_p_do_apply/3(line:237); initial_call:
{mem3_shards,init,['Argument__1']}, ancestors: [mem3_sup,<0.282.0>], messages:
[], links: [<0.283.0>], dictionary: [], trap_exit: false, status: running,
heap_size: 610, stack_size: 27, reductions: 374
{"init terminating in
do_boot",{{error,{{shutdown,{failed_to_start_child,mem3_shards,{{badmatch,file_exists},[{mem3_shards,get_update_seq,0,[{file,"src/mem3_shards.erl"},{line,318}]},{mem3_shards,init,1,[{file,"src/mem3_shards.erl"},{line,206}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,306}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]}}},{mem3_app,start,[normal,[]]}}},[{boot_node,start_app,3,[{file,"dev/boot_node.erl"},{line,134}]},{lists,foldl,3,[{file,"lists.erl"},{line,1261}]},{boot_node,start_app,3,[{file,"dev/boot_node.erl"},{line,124}]},{lists,foldl,3,[{file,"lists.erl"},{line,1261}]},{boot_node,start_app,3,[{file,"dev/boot_node.erl"},{line,124}]},{lists,foldl,3,[{file,"lists.erl"},{line,1261}]},{boot_node,start_app,3,[{file,"dev/boot_node.erl"},{line,124}]},{lists,foldl,3,[{file,"lists.erl"},{line,1261}]}]}}^M
[os_mon] memory supervisor port (memsup): Erlang has closed^M
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed^M
^M
Crash dump was written to: erl_crash.dump^M
init terminating in do_boot ()^M
{noformat}
> JS: dev/run timing out starting up nodes
>
>
> Key: COUCHDB-3402
> URL: https://issues.apache.org/jira/browse/COUCHDB-3402
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Reporter: Joan Touzet
>
> Seen this a bunch of times recently in the Jenkins infrastructure. May be a
> symptom of ASF Jenkins nodes being overloaded.
> {noformat}
> make[1]: Entering directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> # This might help with emfile errors during `make javascript`: ulimit -n 10240
> Failed to start all the nodes. Check the dev/logs/*.log for errors.
> make[1]: *** [javascript] Error 1
> make[1]: Leaving directory `/usr/src/couchdb/apache-couchdb-2.0.0-28dd801'
> make: *** [check] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3244) Replication is broken when database name has "/" and cluster is configured
[
https://issues.apache.org/jira/browse/COUCHDB-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990050#comment-15990050
]
Joan Touzet commented on COUCHDB-3244:
--
Thread, from IRC:
https://groups.google.com/forum/#!searchin/2600hz-dev/couchdb$202.0%7Csort:relevance/2600hz-dev/WO3kXPLdf2M/ApWSZjvPCwAJ
> Replication is broken when database name has "/" and cluster is configured
> --
>
> Key: COUCHDB-3244
> URL: https://issues.apache.org/jira/browse/COUCHDB-3244
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Sergey Safarov
>
> When CouchDB host is configured as standalone server when i can execute
> command
> curl -s -S -X POST http://127.0.0.1:5984/_replicate -H 'Content-Type:
> application/json' -H 'Accept: application/json, text/javascript'
> --data-binary
> '{"source":"http://xxx.xxx.xxx.xxx:5984/account%2f32%2fc2%2f83a70fb3146e584c4743c557b1df","target":"account/32/c2/83a70fb3146e584c4743c557b1df","continuous":false,"create_target":true}'
> And then get responce like
> {"ok":true,"session_id":"a25fa8ed55c970f3ec6dc7e3f641d515","source_last_seq":"424-g1LzeJyt0DsKwkAQBuDFCAqeQBu9gGGziTGdEU9hpbMvYtwklY2N3kRvojfRm8R9BOxESJoZGGY-hl8hhIaZx9GEVSeWcZoe4TzHga8qBopXBRxKpXd6gOi0rus88yAp9GDAAYdEyp-X_8B0pitdNbZv7SiUEkC0t1Nj7xp7Y20COIIA2tt7Y18ae2xtDAJosGxtl31d0VU3zd-Mv3a5sDgRZNGRf3f-w_hb978QnErWkf90_uv7fywII4x25L-db_MfuXyA8ZD_zj__ADLK8AQ","replication_id_version":3,"history":[{"session_id":"a25fa8ed55c970f3ec6dc7e3f641d515","start_time":"Sat,
> 26 Nov 2016 13:51:02 GMT","end_time":"Sat, 26 Nov 2016 13:51:25
> GMT","start_last_seq":0,"end_last_seq":"424-g1LzeJyt0DsKwkAQBuDFCAqeQBu9gGGziTGdEU9hpbMvYtwklY2N3kRvojfRm8R9BOxESJoZGGY-hl8hhIaZx9GEVSeWcZoe4TzHga8qBopXBRxKpXd6gOi0rus88yAp9GDAAYdEyp-X_8B0pitdNbZv7SiUEkC0t1Nj7xp7Y20COIIA2tt7Y18ae2xtDAJosGxtl31d0VU3zd-Mv3a5sDgRZNGRf3f-w_hb978QnErWkf90_uv7fywII4x25L-db_MfuXyA8ZD_zj__ADLK8AQ","recorded_seq":"424-g1LzeJyt0DsKwkAQBuDFCAqeQBu9gGGziTGdEU9hpbMvYtwklY2N3kRvojfRm8R9BOxESJoZGGY-hl8hhIaZx9GEVSeWcZoe4TzHga8qBopXBRxKpXd6gOi0rus88yAp9GDAAYdEyp-X_8B0pitdNbZv7SiUEkC0t1Nj7xp7Y20COIIA2tt7Y18ae2xtDAJosGxtl31d0VU3zd-Mv3a5sDgRZNGRf3f-w_hb978QnErWkf90_uv7fywII4x25L-db_MfuXyA8ZD_zj__ADLK8AQ","missing_checked":106,"missing_found":106,"docs_read":106,"docs_written":106,"doc_write_failures":0}]}
> But if CouchDB node is joined to cluster same command cannot be executed.
> CouchDB not retrun any responce
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3401) EUnit: should_not_remember_docs_in_index_after_backup_restore 500 error
Joan Touzet created COUCHDB-3401:
Summary: EUnit:
should_not_remember_docs_in_index_after_backup_restore 500 error
Key: COUCHDB-3401
URL: https://issues.apache.org/jira/browse/COUCHDB-3401
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
1 failure so far - Ubuntu 16.04, default erlang.
{noformat}
Upgrade and bugs related tests
couchdb_views_tests:159:
should_not_remember_docs_in_index_after_backup_restore...*failed*
in function couchdb_views_tests:'-query_view/4-fun-0-'/2
(test/couchdb_views_tests.erl, line 512)
in call from couchdb_views_tests:query_view/4 (test/couchdb_views_tests.erl,
line 512)
in call from
couchdb_views_tests:'-should_not_remember_docs_in_index_after_backup_restore/1-fun-8-'/1
(test/couchdb_views_tests.erl, line 173)
**error:{assertEqual,[{module,couchdb_views_tests},
{line,512},
{expression,"Code"},
{expected,200},
{value,500}]}
output:<<"">>
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3396) EUnit: failed_to_start_child
Joan Touzet created COUCHDB-3396:
Summary: EUnit: failed_to_start_child
Key: COUCHDB-3396
URL: https://issues.apache.org/jira/browse/COUCHDB-3396
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Reporter: Joan Touzet
Multiple failures in chttpd_db_doc_size_tests across multiple platforms.
{noformat}
module 'chttpd_db_doc_size_tests'
chttpd db max_document_size tests
*** context setup failed ***
**in function test_util:start_applications/2 (src/test_util.erl, line 91)
in call from test_util:start_couch/2 (src/test_util.erl, line 74)
**error:{case_clause,
{error,
{{shutdown,
{failed_to_start_child,couch_secondary_services,
{shutdown,
{failed_to_start_child,
"couch_epi_codechange_monitor|chttpd_handlers|providers",
{noproc,{gen_server,call,...}},
{couch_app,start,[normal,[]]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COUCHDB-3155) Fauxton does not work reverse proxied into a subfolder
[
https://issues.apache.org/jira/browse/COUCHDB-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3155.
--
Resolution: Duplicate
This requires a custom Fauxton build. See COUCHDB-2403 for details.
In short, you edit the app.root and/or app.host variables in
https://github.com/apache/couchdb-fauxton/blob/master/settings.json.default.json
and create and deploy a custom Fauxton build.
> Fauxton does not work reverse proxied into a subfolder
> --
>
> Key: COUCHDB-3155
> URL: https://issues.apache.org/jira/browse/COUCHDB-3155
> Project: CouchDB
> Issue Type: Bug
> Components: Fauxton
>Reporter: Daniel Holth
>
> I like to use couchdb behind nginx in a subdirectory, like so, but Fauxton
> always requests /_session instead of /db/_session for example. Instead,
> Fauxton should build URLs relative to where it was requested from.
> Excerpt from nginx configuration:
> {noformat}
> location /db {
> rewrite /db/(.*) /$1 break;
> proxy_set_header X-Forwarded-For $remote_addr;
> proxy_set_header Host $proxy_host;
> proxy_pass http://127.0.0.1:5984;
> proxy_redirect https://127.0.0.1:5984 https://$host/db;
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-2367) Eliminate plaintext passwords altogether
[ https://issues.apache.org/jira/browse/COUCHDB-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979990#comment-15979990 ] Joan Touzet commented on COUCHDB-2367: -- Bump. [~candeira] do you think you have time to finish this one up, or need some help? Ran square into this one while building packages...Python includes pbkdf2 in hashlib since 2.7.8 which should be in most distributions by now. > Eliminate plaintext passwords altogether > > > Key: COUCHDB-2367 > URL: https://issues.apache.org/jira/browse/COUCHDB-2367 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Javier Candeira >Assignee: Javier Candeira > > In discussion about https://issues.apache.org/jira/browse/COUCHDB-2364, > rnewson and candeira agreed on: > <+rnewson> Maybe spent a little more time on the idea that we remove support > for plaintext passwords entirely? > <+rnewson> I dislike the hash-on-startup thing. > <+rnewson> we could insist that you set up admins via PUT _config > <+rnewson> and remove the hash_unhashed_admins function, and also ignore > non-hashed lines in config > <+rnewson> couchdb 2.0 could simply require the hashed version from the start > (and we'd supply a hashing tool akin to htpasswd in httpd), or > < kandinski> what about PUT _config, it would still exist? > <+rnewson> absolutely, yes. > <+rnewson> the PUT _config can take plaintext passwords (and there's a > ?raw=true iirc to inhibit hashing) since that invokes code *before* we update > the file, so the file never contains plaintext > <+rnewson> basically, the goal is to change couchdb so that password hashing > is done before writing the file, in all cases. if you *don't* put a hashed > value into [admins], the line is simply ignored. > <+rnewson> and that's how we fix the hole. > <+rnewson> [admins] > <+rnewson> foo = bar > <+rnewson> is a couchdb with no admins -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (COUCHDB-3392) admin passwords not overwritten in default.d/*.ini files
[
https://issues.apache.org/jira/browse/COUCHDB-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-3392.
Resolution: Duplicate
Thanks Bob.
> admin passwords not overwritten in default.d/*.ini files
>
>
> Key: COUCHDB-3392
> URL: https://issues.apache.org/jira/browse/COUCHDB-3392
> Project: CouchDB
> Issue Type: Bug
> Components: Config
>Reporter: Joan Touzet
>
> If I create an {{etc/local.d/10-admins.ini}} file with the following text:
> {noformat}
> [admins]
> admin = pass
> {noformat}
> and (re)start CouchDB, the password gets hashed.
> But if I create an {{etc/default.d/10-admins.ini}} with the same content, the
> password is *not* hashed on restart. In either case, the admin user is
> recognized by the config system.
> [~rnewson] I think you implemented this code, would you take a look?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COUCHDB-3392) admin passwords not overwritten in default.d/*.ini files
Joan Touzet created COUCHDB-3392:
Summary: admin passwords not overwritten in default.d/*.ini files
Key: COUCHDB-3392
URL: https://issues.apache.org/jira/browse/COUCHDB-3392
Project: CouchDB
Issue Type: Bug
Components: Config
Reporter: Joan Touzet
If I create an {{etc/local.d/10-admins.ini}} file with the following text:
{noformat}
[admins]
admin = pass
{noformat}
and (re)start CouchDB, the password gets hashed.
But if I create an {{etc/default.d/10-admins.ini}} with the same content, the
password is *not* hashed on restart. In either case, the admin user is
recognized by the config system.
[~rnewson] I think you implemented this code, would you take a look?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COUCHDB-3341) EUnit: config listener unknown failure
[
https://issues.apache.org/jira/browse/COUCHDB-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979335#comment-15979335
]
Joan Touzet commented on COUCHDB-3341:
--
Fourth occurrence, Ubuntu 16.04, default Erlang.
> EUnit: config listener unknown failure
> --
>
> Key: COUCHDB-3341
> URL: https://issues.apache.org/jira/browse/COUCHDB-3341
> Project: CouchDB
> Issue Type: Test
> Components: Test Suite
>Reporter: Joan Touzet
>
> One occurrence in our Jenkins builds so far.
> {noformat}
> module 'couch_log_config_listener_test'
> couch_log_config_listener_test: couch_log_config_test_...*failed*
> in function
> couch_log_config_listener_test:'-check_restart_listener/0-fun-2-'/1
> (test/couch_log_config_listener_test.erl, line 38)
> in call from couch_log_config_listener_test:check_restart_listener/0
> (test/couch_log_config_listener_test.erl, line 38)
> **error:{assertEqual,[{module,couch_log_config_listener_test},
> {line,38},
> {expression,"get_handler ( )"},
> {expected,not_found},
> {value,{config_listener,{couch_log_sup,<0.3192.0>}}}]}
> output:<<"">>
> {noformat}
> No clue what's going on here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COUCHDB-3390) clustered _users/_changes returns error when include_docs=true
[
https://issues.apache.org/jira/browse/COUCHDB-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-3390.
--
Resolution: Fixed
Fix Version/s: 2.1.0
Hi there, thanks for the report. This has already been fixed on master.
> clustered _users/_changes returns error when include_docs=true
> --
>
> Key: COUCHDB-3390
> URL: https://issues.apache.org/jira/browse/COUCHDB-3390
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: CJ Herman
> Fix For: 2.1.0
>
>
> When requesting changes feed for clustered _users DB with include_docs=true,
> an error is returned:
> curl -X GET http://localhost:5984/_users/_changes?include_docs=true
> {"error":"error","reason":"{not_found,nil,\n
> [{couch_users_db,after_doc_read,2,\n
> [{file,\"src/couch_users_db.erl\"},{line,123}]},\n
> {couch_db,open_doc_int,3,[{file,\"src/couch_db.erl\"},{line,1345}]},\n
> {couch_db,open_doc,3,[{file,\"src/couch_db.erl\"},{line,189}]},\n
>{fabric_rpc,doc_member,3,[{file,\"src/fabric_rpc.erl\"},{line,354}]},\n
> {fabric_rpc,changes_enumerator,2,\n
> [{file,\"src/fabric_rpc.erl\"},{line,347}]},\n
> {couch_btree,stream_kv_node2,8,\n
> [{file,\"src/couch_btree.erl\"},{line,783}]},\n
> {couch_btree,fold,4,[{file,\"src/couch_btree.erl\"},{line,220}]},\n
> {couch_db,changes_since,5,\n
> [{file,\"src/couch_db.erl\"},{line,1244}]}]}"}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
