incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: CouchDB crashing at random times
Date Sat, 24 Aug 2013 07:16:26 GMT
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 with
> 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 out
>>> 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. The
>>> following is the link to the error output message.
>>>
>>>
>>>https://gist.github.com/yangtheman/6324540/raw/ccdfe4685d166abe30176e4a5f
>>>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
….

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

Mime
View raw message