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 thanosv@gmail.com designates
 209.85.223.174 as permitted sender)
Subject: Re: CouchDB crashing at random times
References: 
 <CAL+Y1nuhn_hVx1TrE-J=PwRvrmtX=UQ2nJX=hVm1dYj0HZrdVw@mail.gmail.com>
 <CE3D3DD3.1E16%yang.chung@spirent.com>
 <CAL+Y1nuUApjTWpxh-9EH+aYL=tJ+8gYjejM90er=k7-DDp_adg@mail.gmail.com>
From: Thanos Vassilakis <thanosv@gmail.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: 
 <CAL+Y1nuUApjTWpxh-9EH+aYL=tJ+8gYjejM90er=k7-DDp_adg@mail.gmail.com>
Message-Id: <C5474385-9A7F-4A68-BA3C-782A5D617A93@gmail.com>
Date: Sat, 24 Aug 2013 09:57:42 -0400
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

What platform ? And how did you build it ?

On Aug 24, 2013, at 3:16, Dave Cottlehuber <dch@jsonified.com> wrote:

> On 24 August 2013 01:31, Chung, Yang <Yang.Chung@spirent.com> wrote:
>> Hi Dave,
>>=20
>> Thank you so much for your reply!
>>=20
>> 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).
>>=20
>> The following is two new crash logs.
>>=20
>> https://gist.github.com/yangtheman/6324929
>>=20
>> Thank you!
>>=20
>> -Yang
>>=20
>> On 8/23/13 4:10 PM, "Dave Cottlehuber" <dch@jsonified.com> wrote:
>>=20
>>> Hi Yang,
>>>=20
>>>                   "/Users/yangtheman/Library/Application
>>> Support/CouchbaseServer/testgears_test.couch",
>>>=20
>>> This isn't Apache CouchDB, it's Couchbase Server -- from
>>> http://couchbase.com/ which we can't offer support for -- different
>>> product/company etc.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> A+
>>> Dave
>>>=20
>>> On 24 August 2013 00:15, Chung, Yang <Yang.Chung@spirent.com> wrote:
>>>> Hey guys,
>>>>=20
>>>> I am really about to throw my hands up because I can't really figure ou=
t
>>>> why CouchDB keeps during Rails rspec tests.
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>> https://gist.github.com/yangtheman/6324540/raw/ccdfe4685d166abe30176e4a=
5f
>>>> 10
>>>> 41cc86e32df2/gistfile1.txt#
>>>>=20
>>>>=20
>>>> Any help would be much, much appreciated.
>>>>=20
>>>> Thank you!
>>>>=20
>>>> -Yang
>=20
> Hey Yang,
>=20
> TL;DR this looks like a bug in recreate!, it looks like a race cond in
> recreate, where you see:
>=20
> # create a new db but you're told there's already one there:
> PUT /av_tests_test 412
> =E2=80=A6.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> A+
> Dave