The road to 2.0 was long and unfortunately a number of things slipped us by. I think you're the first to try coffeescript on 2.0, that's all. We know coffeescript _works_ because we have tests for it, and those tests can find main-coffee.js in the source tree. The slip was failing to copy it into the 'make release' output only.
B. > On 7 Dec 2016, at 19:34, Brian Lanier <[email protected]> wrote: > > Hi, > I saw your fix and it worked for me. I was kind of hoping for some sort of > bug as I had run out of ideas to try and places to look. For now, its an easy > manual fix for my test cluster. I was able to fully replicate my previous db > from 1.6.1 into 2.0.0 and can continue testing/learning. > > Other than this, its been pretty good minus a few issues with documentation > on setup that have either been addressed or already have an issue open. > Mainly the not well documented way to require users for chtppd and wanting to > lock down ports and access better via the bind address. I see there are > changes coming along those lines anyway. As 2.0 matures, I hope to see some > of the config I need migrated from direct erlang config via environment or > via the vm.args file and into couchdb config directly. > > Thanks for the quick fix and response on this. Was starting to wonder if > couchdb 2.0 was not ready for our needs or if we were doing something > extremely weird with coffeescript. > > Brian > > On 12/7/16 11:22 AM, Robert Samuel Newson wrote: >> Hi Brian, >> >> I got there first. Fix is applied to master and will be in the next release. >> It's as you say, it's the other .js file that's needed. >> >> B. >> >>> On 7 Dec 2016, at 18:45, Brian Lanier <[email protected]> wrote: >>> >>> Hi Jan, >>> I went to open an issue and found one already created. Don't know if it was >>> because of this email or total coincidence. I made the change manually and >>> copied the main-coffee.js from the source directory to my release directory >>> and it looks like it resolved my issues. >>> >>> So looks like this will resolve my issue. Should I add a comment to the >>> issue or is that not necessary? >>> >>> https://issues.apache.org/jira/browse/COUCHDB-3252 >>> >>> Thanks >>> Brian >>> >>> On 12/7/16 1:26 AM, Jan Lehnardt wrote: >>>> Heya Brian, >>>> >>>> this looks serious, >>>> >>>> could you open an issue on http://issues.apache.org/jira/browse/COUCHDB so >>>> we can track this? >>>> >>>> Thank you! >>>> Best >>>> Jan >>>> -- >>>> >>>>> On 6 Dec 2016, at 20:45, Brian Lanier <[email protected]> wrote: >>>>> >>>>> Hello, >>>>> I have a 2 node couchdb 2.0 cluster setup to start testing things. It has >>>>> been running great until I went to replicate a current db into the >>>>> cluster from 1.6.1. The replication locks up and fails and both nodes >>>>> start spitting out a bunch of repeating log lines indicating something is >>>>> crashing. After further inspection, it seems the problem occurs when the >>>>> replication hits the _design docs, all of which are written in >>>>> coffeescript. >>>>> >>>>> I switched to just trying to create a simple coffeescript design doc via >>>>> fauxton and via curl and I get the same process crashing errors. I have >>>>> tried taking a javascript design doc that is entered into a test db and >>>>> just changing the language to coffeescript. This causes the error when I >>>>> would expect either validation errors or for the design doc to crash when >>>>> trying to use it. I can create an empty design doc with the language set >>>>> to coffeescript and this will save, but it has no views or anything else. >>>>> >>>>> This is all after changing the query server definition for coffeescript >>>>> to point to the file included. By default, the config points to >>>>> ./share/server/main-coffee.js which is not included in the release. I >>>>> have changed it to ./share/server/coffee-script.js which is included. Not >>>>> sure if that was correct or not, but seemed to match what was done in >>>>> previous releases and I couldn't find much info in searches relating to >>>>> coffeescript specific config. >>>>> >>>>> Config on both nodes is the same. >>>>> >>>>> For testing purposes, here is the design doc I am testing with and the >>>>> command used to insert the doc: (Same file and command worked on couchdb >>>>> 1.6.1 server) >>>>> curl -X PUT >>>>> http://admin:[email protected]:5984/bs/_design/simple_test -d >>>>> @/simple_test.json >>>>> {"error":"unknown_error","reason":"undefined"} >>>>> [email protected]:~ # >>>>> >>>>> simple_test.json: >>>>> [email protected]:~ # cat /simple_test.json >>>>> {"views":{"by_conflicts":{"map":"(doc)->\n if doc._conflicts\n emit >>>>> doc._conflicts, >>>>> null\n"}},"filters":{},"lists":{},"language":"coffeescript"} >>>>> >>>>> The errors I see in the logs on both servers as soon as I try to save the >>>>> design doc with a coffeescript view: >>>>> >>>>> Node 1 >>>>> debug] 2016-12-06T19:27:22.961461Z [email protected] <0.17765.31> >>>>> 79e07a0d50 cache miss for admin >>>>> [debug] 2016-12-06T19:27:22.963456Z [email protected] <0.17765.31> >>>>> 79e07a0d50 no record of user admin >>>>> [debug] 2016-12-06T19:27:22.969784Z [email protected] <0.17799.31> >>>>> -------- OS Process Start :: #Port<0.12902> >>>>> [debug] 2016-12-06T19:27:22.970009Z [email protected] <0.17799.31> >>>>> -------- OS Process #Port<0.12902> Input :: >>>>> ["reset",{"reduce_limit":true,"timeout":5000}] >>>>> [info] 2016-12-06T19:27:23.014571Z [email protected] <0.216.0> -------- >>>>> couch_proc_manager <0.17799.31> died normal >>>>> [error] 2016-12-06T19:27:23.014599Z [email protected] <0.17789.31> >>>>> -------- OS Process Error <0.17799.31> :: >>>>> {os_process_error,{exit_status,0}} >>>>> [debug] 2016-12-06T19:27:23.016954Z [email protected] <0.17809.31> >>>>> -------- OS Process Start :: #Port<0.12903> >>>>> [debug] 2016-12-06T19:27:23.017185Z [email protected] <0.17809.31> >>>>> -------- OS Process #Port<0.12903> Input :: >>>>> ["reset",{"reduce_limit":true,"timeout":5000}] >>>>> [info] 2016-12-06T19:27:23.054046Z [email protected] <0.216.0> -------- >>>>> couch_proc_manager <0.17809.31> died normal >>>>> [error] 2016-12-06T19:27:23.054136Z [email protected] <0.17789.31> >>>>> -------- OS Process Error <0.17809.31> :: >>>>> {os_process_error,{exit_status,0}} >>>>> >>>>> Node 2 >>>>> [debug] 2016-12-06T19:27:22.978069Z [email protected] <0.3683.1> >>>>> -------- OS Process Start :: #Port<0.7040> >>>>> [debug] 2016-12-06T19:27:22.986184Z [email protected] <0.3683.1> >>>>> -------- OS Process #Port<0.7040> Input :: >>>>> ["reset",{"reduce_limit":true,"timeout":5000}] >>>>> [info] 2016-12-06T19:27:23.051441Z [email protected] <0.216.0> -------- >>>>> couch_proc_manager <0.3683.1> died normal >>>>> [error] 2016-12-06T19:27:23.051560Z [email protected] <0.3681.1> >>>>> -------- OS Process Error <0.3683.1> :: {os_process_error,{exit_status,0}} >>>>> [debug] 2016-12-06T19:27:23.054276Z [email protected] <0.3687.1> >>>>> -------- OS Process Start :: #Port<0.7082> >>>>> [debug] 2016-12-06T19:27:23.054564Z [email protected] <0.3687.1> >>>>> -------- OS Process #Port<0.7082> Input :: >>>>> ["reset",{"reduce_limit":true,"timeout":5000}] >>>>> [info] 2016-12-06T19:27:23.095047Z [email protected] <0.216.0> -------- >>>>> couch_proc_manager <0.3687.1> died normal >>>>> [error] 2016-12-06T19:27:23.095175Z [email protected] <0.3681.1> >>>>> -------- OS Process Error <0.3687.1> :: {os_process_error,{exit_status,0}} >>>>> >>>>> couchdb is started via systemd and I am not seeing anything in the log >>>>> from standard out/error when this happens. As you can see I turned up the >>>>> logging to debug and just not getting any good info. Run out of ideas to >>>>> try to get more info or resolve this. >>>>> >>>>> I'm not sure if I am running into a configuration error, setup error, >>>>> install error or a bug. Any help on this would be appreciated. I can >>>>> supply any additional info as needed as this is a testing cluster and not >>>>> in production yet. >>>>> >>>>> Running on Ubuntu 16.04 using Erlang/OTP 19 (erlang-base-hipe: Installed: >>>>> 1:19.1-1) >>>>> >>>>> Thanks >>>>> Brian >
