couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Lanier <bri...@amco.me>
Subject Re: Problems with coffeescript in design docs
Date Wed, 07 Dec 2016 20:26:49 GMT
Sorry, I didn't mean to infer I was unhappy with anything. On the 
contrary, considering the amount of work that was done, I'm extremely 
impressed so far. I sort of expected more trouble setting up the cluster 
the first time as I went straight for binding the IP's of the services, 
firewalling the ports, requiring users, etc. Once I understood a few 
things and fixed the connections/config, it just worked!

Thanks again for the quick fix.

Brian

On 12/7/16 11:53 AM, Robert Samuel Newson wrote:
> 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 <brianl@amco.me> 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 <brianl@amco.me> 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 <brianl@amco.me> 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:hiddenpassword@stage.cdb-n1:5984/bs/_design/simple_test
-d @/simple_test.json
>>>>>> {"error":"unknown_error","reason":"undefined"}
>>>>>> root@stage.cdb-n1:~ #
>>>>>>
>>>>>> simple_test.json:
>>>>>> root@stage.cdb-n1:~ # 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 cdb-n1@stage.cdb-n1 <0.17765.31>
79e07a0d50 cache miss for admin
>>>>>> [debug] 2016-12-06T19:27:22.963456Z cdb-n1@stage.cdb-n1 <0.17765.31>
79e07a0d50 no record of user admin
>>>>>> [debug] 2016-12-06T19:27:22.969784Z cdb-n1@stage.cdb-n1 <0.17799.31>
-------- OS Process Start :: #Port<0.12902>
>>>>>> [debug] 2016-12-06T19:27:22.970009Z cdb-n1@stage.cdb-n1 <0.17799.31>
-------- OS Process #Port<0.12902> Input :: ["reset",{"reduce_limit":true,"timeout":5000}]
>>>>>> [info] 2016-12-06T19:27:23.014571Z cdb-n1@stage.cdb-n1 <0.216.0>
-------- couch_proc_manager <0.17799.31> died normal
>>>>>> [error] 2016-12-06T19:27:23.014599Z cdb-n1@stage.cdb-n1 <0.17789.31>
-------- OS Process Error <0.17799.31> :: {os_process_error,{exit_status,0}}
>>>>>> [debug] 2016-12-06T19:27:23.016954Z cdb-n1@stage.cdb-n1 <0.17809.31>
-------- OS Process Start :: #Port<0.12903>
>>>>>> [debug] 2016-12-06T19:27:23.017185Z cdb-n1@stage.cdb-n1 <0.17809.31>
-------- OS Process #Port<0.12903> Input :: ["reset",{"reduce_limit":true,"timeout":5000}]
>>>>>> [info] 2016-12-06T19:27:23.054046Z cdb-n1@stage.cdb-n1 <0.216.0>
-------- couch_proc_manager <0.17809.31> died normal
>>>>>> [error] 2016-12-06T19:27:23.054136Z cdb-n1@stage.cdb-n1 <0.17789.31>
-------- OS Process Error <0.17809.31> :: {os_process_error,{exit_status,0}}
>>>>>>
>>>>>> Node 2
>>>>>> [debug] 2016-12-06T19:27:22.978069Z cdb-n2@stage.cdb-n2 <0.3683.1>
-------- OS Process Start :: #Port<0.7040>
>>>>>> [debug] 2016-12-06T19:27:22.986184Z cdb-n2@stage.cdb-n2 <0.3683.1>
-------- OS Process #Port<0.7040> Input  :: ["reset",{"reduce_limit":true,"timeout":5000}]
>>>>>> [info] 2016-12-06T19:27:23.051441Z cdb-n2@stage.cdb-n2 <0.216.0>
-------- couch_proc_manager <0.3683.1> died normal
>>>>>> [error] 2016-12-06T19:27:23.051560Z cdb-n2@stage.cdb-n2 <0.3681.1>
-------- OS Process Error <0.3683.1> :: {os_process_error,{exit_status,0}}
>>>>>> [debug] 2016-12-06T19:27:23.054276Z cdb-n2@stage.cdb-n2 <0.3687.1>
-------- OS Process Start :: #Port<0.7082>
>>>>>> [debug] 2016-12-06T19:27:23.054564Z cdb-n2@stage.cdb-n2 <0.3687.1>
-------- OS Process #Port<0.7082> Input  :: ["reset",{"reduce_limit":true,"timeout":5000}]
>>>>>> [info] 2016-12-06T19:27:23.095047Z cdb-n2@stage.cdb-n2 <0.216.0>
-------- couch_proc_manager <0.3687.1> died normal
>>>>>> [error] 2016-12-06T19:27:23.095175Z cdb-n2@stage.cdb-n2 <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


Mime
View raw message