Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4369BE84E for ; Mon, 21 Jan 2013 17:51:06 +0000 (UTC) Received: (qmail 1264 invoked by uid 500); 21 Jan 2013 17:51:04 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 1219 invoked by uid 500); 21 Jan 2013 17:51:04 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 1210 invoked by uid 99); 21 Jan 2013 17:51:04 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2013 17:51:04 +0000 Received: from localhost (HELO mail-vc0-f177.google.com) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2013 17:51:04 +0000 Received: by mail-vc0-f177.google.com with SMTP id m18so1465817vcm.8 for ; Mon, 21 Jan 2013 09:51:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.156.7 with SMTP id wa7mr17816761vdb.46.1358790663361; Mon, 21 Jan 2013 09:51:03 -0800 (PST) Received: by 10.52.68.209 with HTTP; Mon, 21 Jan 2013 09:51:03 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 12:51:03 -0500 Message-ID: Subject: Re: View creation error on specific DB From: Robert Newson To: "user@couchdb.apache.org" Content-Type: text/plain; charset=ISO-8859-1 Nope, the -S parameter has never done what it claims. B. On 21 January 2013 12:48, Donal Simmie wrote: > I did try your approach Paul before I saw Robert's follow up and the same > thing happened. > > The error log is here in case sheds any light: > > http://pastebin.com/nFxU80FG - it doesn't for me ;) > > This time I was using a simpler emit than the second param being doc and > wouldn't generally emit the entire doc but thanks for link to that article > Dave. > > This was the view code I used this time: > > function(doc) { > emit(doc.user.screen_name, doc.user.id); > } > > Robert as for the view stack size setting not being a useful setting, it is > suggested here > http://wiki.apache.org/couchdb/Performance#JavaScript_View_Server that this > can be altered if there a problem in the logs that indicates stack size > might be an issue. Is this still valid advice? > > Thanks for the suggestions. > > > > On Mon, Jan 21, 2013 at 5:22 PM, Paul Davis wrote: > >> Well ain't that a knock in the teeth. Never seen that note before so it >> must've been something lots of people were mistaking that API for. >> >> I've got no idea how to fix this then. >> >> >> On Mon, Jan 21, 2013 at 11:19 AM, Robert Newson >> wrote: >> >> > Paul, you know that -S doesn't change the stack size just the size of >> > stack fragments. It's a useless setting afaict; >> > >> > from >> > >> https://developer.mozilla.org/en-US/docs/SpiderMonkey/JSAPI_Reference/JS_NewContext >> > >> > "The stackchunksize parameter does not control the JavaScript stack >> > size. (The JSAPI does not provide a way to adjust the stack depth >> > limit.) Passing a large number forstackchunksize is a mistake." >> > >> > B. >> > >> > On 21 January 2013 11:39, Paul Davis >> wrote: >> > > Sounds like a stack size issue. Try setting -S to something largish >> > > (10485760 or so) on the couchjs command line in your default.ini >> > > >> > > >> > > On Mon, Jan 21, 2013 at 10:27 AM, Donal Simmie > > >wrote: >> > > >> > >> As an update I have tried numerous approaches to attempt to >> > fix/workaround >> > >> this problem: >> > >> >> > >> 1. Compacting the database. >> > >> 2. Replicating to a local copy of the DB and retrying view creation. >> > >> 3. Dumping DB contents to JSON with dump.py and loading into another >> DB >> > >> with load.py >> > >> >> > >> None of these worked. >> > >> >> > >> After downloading the couchdb-python library I added the python view >> > server >> > >> to Futon and ran view code in python and this does fix the problem. >> > >> >> > >> So if the problem is with the javascript view server, does this help >> in >> > >> identifying what the issue might be and how I could fix it? >> > >> >> > >> E.g. >> > >> >> > >> Bad entry in config file, >> > >> Corrupt document(s), >> > >> Something else?? >> > >> >> > >> Thanks >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> On Thu, Jan 17, 2013 at 2:59 PM, Donal Simmie > > >> >wrote: >> > >> >> > >> > I am getting an os error on view creation for a certain database. >> All >> > my >> > >> > views for other databases are working but I cannot create any on >> this >> > one >> > >> > without it failing. >> > >> > >> > >> > The error message is: os_process_error,{exit_status,0}} >> > >> > >> > >> > I was trying a proper view but even this basic one is broken: >> > >> > >> > >> > function(doc) { >> > >> > emit(1, doc); >> > >> > } >> > >> > >> > >> > Note: >> > >> > I have been using Futon for view creation. >> > >> > The all documents view is fine and documents themselves can be >> viewed. >> > >> > I altered the default configuration file by adding a compactions >> > section >> > >> > with the following key/value pair: -default: [{db_fragmentation, >> > "70%"}, >> > >> > {view_fragmentation, "60%"}, {from, "23:00"}, {to, "04:00"}]. >> > >> > The DB in question contains 3.6 GB of data. >> > >> > >> > >> > Version: 1.2 >> > >> > Os: Mac OS X 10.8.2 >> > >> > >> > >> > The trace in the log file is available here: >> > >> http://pastebin.com/AdrJ6jeB >> > >> > >> > >> > Any suggestions please? >> > >> > >> > >> >> > >>