Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dch@jsonified.com designates
 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CE3D3DD3.1E16%yang.chung@spirent.com>
References: 
 <CAL+Y1nuhn_hVx1TrE-J=PwRvrmtX=UQ2nJX=hVm1dYj0HZrdVw@mail.gmail.com>
	<CE3D3DD3.1E16%yang.chung@spirent.com>
Date: Sat, 24 Aug 2013 09:16:26 +0200
Message-ID: 
 <CAL+Y1nuUApjTWpxh-9EH+aYL=tJ+8gYjejM90er=k7-DDp_adg@mail.gmail.com>
Subject: Re: CouchDB crashing at random times
From: Dave Cottlehuber <dch@jsonified.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 24 August 2013 01:31, Chung, Yang <Yang.Chung@spirent.com> wrote:
> Hi Dave,
>
> Thank you so much for your reply!
>
> I have downloaded and installed CouchDB 1.3.1 and tried again. The same
> errors occurred. I don't know if you can tell, but we start each test wit=
h
> empty database by issuing CouchDB_handle.recreate! (CouchRest method) on
> three databases
> (http://rdoc.info/github/couchrest/couchrest/CouchRest/Database#recreate%=
21
> -instance_method).
>
> The following is two new crash logs.
>
> https://gist.github.com/yangtheman/6324929
>
> Thank you!
>
> -Yang
>
> On 8/23/13 4:10 PM, "Dave Cottlehuber" <dch@jsonified.com> wrote:
>
>>Hi Yang,
>>
>>                    "/Users/yangtheman/Library/Application
>>Support/CouchbaseServer/testgears_test.couch",
>>
>>This isn't Apache CouchDB, it's Couchbase Server -- from
>>http://couchbase.com/ which we can't offer support for -- different
>>product/company etc.
>>
>>Having said that, at this point in time, I think there was not much
>>difference between versions, but the version numbers also don't line
>>up and we don't have the equivalent source either so it's hard to tell
>>for sure.
>>
>>Could you re-test this with a "pure" Apache CouchDB release from
>>https://couchdb.apache.org/#download and see if this issue is still
>>present? I think 1.3.1 should not be too different for you, and
>>includes fixes for some possible causes.
>>
>>A+
>>Dave
>>
>>On 24 August 2013 00:15, Chung, Yang <Yang.Chung@spirent.com> wrote:
>>> Hey guys,
>>>
>>> I am really about to throw my hands up because I can't really figure ou=
t
>>> why CouchDB keeps during Rails rspec tests.
>>>
>>> I set the log level to "debug" to get more error messages, but I don't
>>> think there is any clue (at least not to me) why server is crashing. Th=
e
>>> following is the link to the error output message.
>>>
>>>
>>>https://gist.github.com/yangtheman/6324540/raw/ccdfe4685d166abe30176e4a5=
f
>>>10
>>> 41cc86e32df2/gistfile1.txt#
>>>
>>>
>>> Any help would be much, much appreciated.
>>>
>>> Thank you!
>>>
>>> -Yang

Hey Yang,

TL;DR this looks like a bug in recreate!, it looks like a race cond in
recreate, where you see:

# create a new db but you're told there's already one there:
PUT /av_tests_test 412
=85.

Perhaps couchrest's recreate! should handle this with a check for the
completed deletion, maybe HEAD /db (or a simple GET would do too). Or
maybe couch's DELETE /db should return a 202 http://httpstatus.es/202
by default.

Anyway,  I suggest you re-try this with delayed commits off, `curl
-XPUT http://admin:passwd@localhost:5984/_config/couchdb/delayed_commits
--data-binary '"false"'` and if this persists, report on the couchrest
group.

BTW contrary to popular belief, in Erlang, the stack trace itself is
not necessarily a reason for panic, it can occur normally e.g. when
certain config parameters are changed, or as various processes start
up or terminate & clean up. So, the stuff happening before the erlang
stack trace is also useful - we can see what was going on prior to the
stacktrace such as the HTTP calls & the associated pids.

A+
Dave