On Mar 1, 2012, at 19:18 , Stefan Kögl wrote: > On Thu, Mar 1, 2012 at 4:52 PM, Jan Lehnardt <j...@apache.org> wrote: >> Can you tell us how you installed 1.2.x? Is it a fresh installation, >> did you do an in-place update from an earlier installation (earlier >> 1.2.x or 1.1.x or 1.0.x? > > I first did a fresh install of 1.2.x using R15B. I then removed R15B, > installed R14B04 (both from source), compiled 1.2.x with the patch I > mentioned earlier, and did an in-place update. > > If this is a problem, I could remove CouchDB first and do a fresh > install instead. What would be the preferred way to do a clean > uninstall?
I don't want to claim that this is definitely the cause for your problem, but it'd be great if you could do a clean, fresh, empty install to make sure we can rule that out as :) Cheers Jan -- > > > -- Stefan > > >> On Mar 1, 2012, at 12:17 , Stefan Kögl wrote: >> >>> Hello, >>> >>> My experiments to replicate some live data / traffic to a CouchDB >>> 1.2.x (running the current 1.2.x branch + the patch from [1]) that >>> sparked the indexing speed discussions, did also yield another >>> (potential) problem. First sorry for not further reporting back any >>> performance measurements, but I didn't yet find the time to run the >>> tests on my machines. >>> >>> Anyway, I found the following stack traces in my log (after noticing >>> that some requests failed and compaction of a view stopped) >>> >>> http://skoegl.net/~stefan/tmp/couchdb-1.2.x-crash.txt >>> >>> The files starts at the first failed requests. Every request before >>> that returned a positiv (ie 2xx) status code. The crash might have >>> some "natural" reason (such as timeouts, lack of RAM, etc), but I'm >>> not sure how to interpret Erlang stack traces. Can somebody point me >>> in the right direction for diagnosing the problem? >>> >>> >>> Thanks, >>> >>> -- Stefan >>> >>> >>> [1] http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w >>
