Startup Failure - Reason: {app_would_not_start,mapreduce}
I've built the lastest branch from source on a Solaris host. When I start the server using install/bin/couchbase-server, ERLang provides the following error for me but I don't have much else that is reported as going wrong. Can anyone provide insight as to what this means or where I should be looking to figure out why the server will not start?
Thank you in advance.
=SUPERVISOR REPORT==== 18-Jul-2012::14:45:53 ===
Supervisor: {local,cb_couch_sup}
Context: start_error
Reason: {app_would_not_start,mapreduce}
Offender: [{pid,undefined},
{name,couch_app},
{mfargs,{couch_app,start,
[fake,
["/u01/app/couch/couchbase/src/couchbase-2.0x/install/etc/couchdb/default.ini",
"/u01/app/couch/couchbase/src/couchbase-2.0x/install/etc/couchdb/local.ini"]]}},
{restart_type,permanent},
{shutdown,5000},
{child_type,supervisor}]
Thanks Filipe. I did pass disable-spidermonkey and disable-v8 as a couchdb_EXTRA_OPTIONS during the gmake phase, but after multiple different attempts. I am going start with a fresh workspace and try again. Do you know of any other locations I can look for additional information in the logs during startup?
Thanks again.
There should be something in the errors.1 log file.
If you paste it somewhere, I'm able to analyze it a bit.
But mapreduce has good chances of failing always to start if V8 support is not enabled.
My first step would be to see if V8 can run on Solaris x86, like build it from source and run its unit tests (official site http://code.google.com/p/v8/ doesn't say that Solaris is supported).
Thanks Filipe. errors.1 does not yet exist on the systems so I don't think I have an option for more information. I'll try installing v8 but I'm not confident that it will work. I did notice that there was a change in the Makefiles for 2.0dp4 and the latest version. The latest version specifically sets the v8 path whereas 2.0dp4 set the js path. Not sure if this change is causing confusion when trying to add --disable-v8....
The js path in DP4 and older versions is the path to the mozilla spidermonkey shared library.
Before, our couchdb (just like apache couchdb) used an external process, written in C which linked to spidermonkey, to run map/reduce functions. Communication with the Erlang VM was though stdin/stdout.
Shortly after DP4 we changed that, so that we have now some C++ code that uses V8 running directly in the Erlang VM, as an extension. This improves performance a lot, not because of V8 most of the time (as most map/reduce functions are very simple), but because of the in-process map/reduce engine and no more stdin/stdout communication.
Without trying building/running unit tests V8 on Solaris x86, I can't tell further what the problem can be exactly. V8 team doesn't list Solaris as officially supported, but their build system config as some Solaris specific settings, so it might work there (expect if on a SPARC cpu).
Thanks Filipe. I'll try to get V8 going on the host.
The mapreduce application uses the Google V8 shared library, so perhaps it's not able to find it/load it.
Did you pass --disable-v8 to couchdb's configure script?
I'm not sure if V8 compiles/works on Solaris at all (even x86, SPARC is known to not be supported).
Couchbase doesn't officially support Solaris at the moment, but we try to make it source/build compatible as most as possible (one of our engineers uses Solaris both on x86 and SPARC). Will ask him to give his feedback here if he has anything to add.