Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.211.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=hOdApQpeuai7Vg/lJ5del6jkZZ+sv9to9q1cig4yvrNyEShb/np3UDC2x9BxvoBGUJ
         1ZjPJN9y5IForsD9vxkF5AZgOXnl+CkMJ0S46I1aRllXKtwtuAS9wmtuA0Bvz3WSU79q
         Ppye/yTZ8WdvhEAoeM15sH/ZjQHXvzZeRqmY8=
MIME-Version: 1.0
In-Reply-To: <A60F21CC-9C57-4202-84C1-04BEF84CD141@apache.org>
References: <6cfccb3d0910030910m678c9157o811a57e02ffbeff0@mail.gmail.com>
	 <6cfccb3d0910031824q5d9362c2k7719b32a779e956f@mail.gmail.com>
	 <1521F562-7878-423B-BEC3-FF2A1916DA0C@gmail.com>
	 <6cfccb3d0910032307i1df64f79u437d5c803bff2c50@mail.gmail.com>
	 <A60F21CC-9C57-4202-84C1-04BEF84CD141@apache.org>
Date: Sun, 4 Oct 2009 15:30:09 -0400
Message-ID: <e2111bbb0910041230x1ccd000craa1ca75609b08aa1@mail.gmail.com>
Subject: Re: Timeout Error when trying to access views + Indexing problems
From: Paul Davis <paul.joseph.davis@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 4, 2009 at 1:19 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> Hi Glenn, I saw something like this once, but unfortunately I wasn't able=
 to
> resolve it. =A0Can you try the following?
>
> 1) Start couchdb with the -i option to get an interactive shell
>
> 2) At the prompt, try to open the view file and read the header
>
> {ok, Fd} =3D
> couch_file:open("/vol/couchdb/var/lib/couchdb/.searchlight_production_des=
ign/5f190ffb2ed589746e8796d2423869ac.view").
> couch_file:read_header(Fd).
>
> In my case, that call timed out, and the stacktrace during normal operati=
on
> was exactly the one you showed earlier in this thread. =A0Best,
>
> Adam
>

Sounds like the header was borked and the timeout is because its
seeking back through the index file to find the previous one. Assuming
a long enough indexing run, it could theoretically be possible to take
longer than 5 seconds and cause a timeout in the gen_server. At least,
according to my brain debugger.

> On Oct 4, 2009, at 2:07 AM, Glenn Rempe wrote:
>
>> Thanks for the reply Paul. =A0Some comments below.
>>
>> Also, just for full disclosure, the CouchDB I am working on was moved ou=
t
>> of
>> another couchdb and it was originally created using CDB 0.9.1. =A0I show=
 a
>> dir
>> listing below that indicates exactly what was moved.
>>
>> On Sat, Oct 3, 2009 at 6:46 PM, Paul Joseph Davis <
>> paul.joseph.davis@gmail.com> wrote:
>>
>>> Glenn,
>>>
>>> This sounds like your map function is timing out which causes the error=
.
>>> You could try upping the os process timeout setting in the config.
>>>
>>>
>> When I go into futon and select one of my views in my design doc it
>> *always*
>> consistently pops up a javascript alert with the error text at ~5 second=
s
>> after selecting the view. =A0It doesn't seem to matter what else I do. =
=A0It
>> also didn't vary when I changed the os_process_timeout value in futon as
>> you
>> suggested from 5000 to 25000. =A0Can you explain exactly what this
>> particular
>> param is doing? =A0I assume the value is milliseconds?
>>
>>
>>> To see what's going on you can increase to debug logging or use the log
>>> function in your maps. There's also the status page in futon which I
>>> think
>>> you said you were looking at.
>>>
>>>
>> Yes, I was previously looking at the status page. =A0But now since I've
>> upgraded to trunk I never see any indexing activity happening in the
>> status
>> page no matter what I do.
>>
>>
>>> If indexing crashes it should just pick up where it left off when you
>>> retrigger. Use the status page to verify. If it's not then let us know.
>>>
>>>
>> Can you clarify, is this also the case when no index has ever successful=
ly
>> run? =A0I was wondering if I first need to get through at least one inde=
x
>> session (maybe with a smaller amount of records) prior to incremental
>> indexing working as expected.
>>
>> Is there any way to determine what percentage of the total records have
>> been
>> added to the index?
>>
>> For your info, here are the contents of the DB dir. =A0You can see the m=
ain
>> DB
>> is 42GB now (~17 million records).
>>
>>
>> root@ip-10-250-55-239:/home/rails/underscore-sync-mysql-to-couchdb/share=
d/log#
>> ls -la /vol/couchdb/var/lib/couchdb
>> total 41674956
>> drwxr-xr-x 3 couchdb root =A0 =A0 =A0 =A0 =A0 =A0 78 2009-10-04 00:46 .
>> drwxr-xr-x 3 couchdb root =A0 =A0 =A0 =A0 =A0 =A0 20 2009-10-03 05:02 ..
>> -rw-r--r-- 1 couchdb couchdb 42675073133 2009-10-04 02:13
>> searchlight_production.couch
>> drwxr-xr-x 2 couchdb couchdb =A0 =A0 =A0 =A0 120 2009-10-03 06:02
>> .searchlight_production_design
>>
>>
>> root@ip-10-250-55-239:/home/rails/underscore-sync-mysql-to-couchdb/share=
d/log#
>> ls -la /vol/couchdb/var/lib/couchdb/.searchlight_production_design/
>> total 33700196
>> drwxr-xr-x 2 couchdb couchdb =A0 =A0 =A0 =A0 120 2009-10-03 06:02 .
>> drwxr-xr-x 3 couchdb root =A0 =A0 =A0 =A0 =A0 =A0 78 2009-10-04 00:46 ..
>> -rw-r--r-- 1 couchdb couchdb =A09819347287 2009-10-03 08:04
>> 5f190ffb2ed589746e8796d2423869ac.view
>> -rw-r--r-- 1 couchdb couchdb =A0 =A091402872 2009-10-03 06:03
>> b127a58306fb8e7858cd1a92f8398511.view
>> -rw-r--r-- 1 couchdb couchdb 24598236884 2009-10-02 13:00
>> SearchDocument.view
>>
>>
>>
>>> If you can't find anything in the debug logs then ping the lust and we'=
ll
>>> get into trying to duplicate.
>>>
>>>
>> I have turned on the 'debug' level in the logs and that provided me with
>> the
>> info I previously provided. =A0I'll try to use the log function in the m=
ap
>> and
>> see if that shows anything.
>>
>> Thanks for helping. =A0If it comes to it, I may be able to make a snapsh=
ot
>> of
>> this EBS volume and start a host that you could login to and get your
>> hands
>> directly on it if that would be helpful.
>>
>> Glenn
>
>