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 <[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

Reply via email to