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 D2541E83C for ; Mon, 21 Jan 2013 17:48:42 +0000 (UTC) Received: (qmail 91912 invoked by uid 500); 21 Jan 2013 17:48:41 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 91864 invoked by uid 500); 21 Jan 2013 17:48:41 -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 91856 invoked by uid 99); 21 Jan 2013 17:48:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2013 17:48:41 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of donal.simmie@gmail.com designates 209.85.210.175 as permitted sender) Received: from [209.85.210.175] (HELO mail-ia0-f175.google.com) (209.85.210.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2013 17:48:37 +0000 Received: by mail-ia0-f175.google.com with SMTP id r4so2732054iaj.20 for ; Mon, 21 Jan 2013 09:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=LiZnA1hX3vY9ZzZUziRnhEQjEdgq8vZroDTJtpe6WAs=; b=sVYajoQuYFdtlLgs0NWIvVWow3edLMZmgpDoBp4ddndbsTHoN/+iMRuhxFe4qLgAzG AmW8RpA/7FfgIqmVgMb1/4GLt1J//yhutGmXEDSsGx393zbg5RZJVCfw5MjUOf7TnGqR DUs5QhBDSFfSwuCEu1okcQG+K/i5bhJ6WHoqvGA/KiL/KmPWNg/zXFCD+4P3QS0vsxBa nqXSXm+7CaZQHqRrYfPTGoo2n3ZtVIUvtjBHjOfN0LOQLIGR1Fwt1K8bSyMctpQ67QkH iyKWR8q9VAJk99vTX5G5n+bJXUbW/mW1ccZbxaqJZdLSTHBJnlO4BHdTHBiZvgdGED2Y x1SA== MIME-Version: 1.0 X-Received: by 10.50.152.198 with SMTP id va6mr9723834igb.42.1358790496782; Mon, 21 Jan 2013 09:48:16 -0800 (PST) Received: by 10.64.145.8 with HTTP; Mon, 21 Jan 2013 09:48:16 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 17:48:16 +0000 Message-ID: Subject: Re: View creation error on specific DB From: Donal Simmie To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=e89a8f3ba037e2887304d3d01043 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f3ba037e2887304d3d01043 Content-Type: text/plain; charset=ISO-8859-1 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? > > >> > > > >> > > > --e89a8f3ba037e2887304d3d01043--