incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: CouchDB crashing at random times
Date Sat, 24 Aug 2013 07:16:26 GMT
On 24 August 2013 01:31, Chung, Yang <> 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
> (
> -instance_method).
> The following is two new crash logs.
> Thank you!
> -Yang
> On 8/23/13 4:10 PM, "Dave Cottlehuber" <> wrote:
>>Hi Yang,
>>                    "/Users/yangtheman/Library/Application
>>This isn't Apache CouchDB, it's Couchbase Server -- from
>> 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
>> 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.
>>On 24 August 2013 00:15, Chung, Yang <> 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.
>>> 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
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

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.


View raw message