Ooh, didn't spot that there was a fix, so that'd be without the fix. Martin
On 25 Mar 2012, at 16:26, Robert Newson wrote: > Martin, > > Is that with or without the fix for COUCHDB-1445? > > B. > > On 25 March 2012 16:06, Martin Hewitt <[email protected]> wrote: >> I've just restarted our CouchDB instance and, as before, all the views have >> started to rebuild from scratch. >> >> I've loaded a rebuilding view with ?stale=ok, and it appears to load the >> view as it would be before the server was restarted, i.e. the view still >> exists as calculated before the server was restarted and the rebuild began, >> but the _utils/status.html page shows all views as rebuilding from scratch. >> >> Martin >> >> On 20 Mar 2012, at 16:49, Robert Newson wrote: >> >>> Very curious, would love to know more. >>> >>> On 20 March 2012 16:33, Martin Hewitt <[email protected]> wrote: >>>> Hi Robert, >>>> >>>> For one view, whenever we loaded it, but every time we loaded it, would >>>> produce a stack trace and not the view. Restarting the CouchDB instance >>>> restored the view to working order. >>>> >>>> I'll try and dig out the stack trace, but it was the perpetual, continual >>>> problem with this view that led us to take the "nuclear option" and >>>> restart. >>>> >>>> Martin >>>> >>>> On 20 Mar 2012, at 14:24, Robert Newson wrote: >>>> >>>>> Can you describe "it was repeatedly crashing with gen_server timeouts" >>>>> in more detail? This sounds non-fatal to me but can look alarming if >>>>> you're not used to the erlang approach to error handling. It might be >>>>> that you're restarting for no good reason. >>>>> >>>>> B. >>>>> >>>>> On 20 March 2012 14:20, Robert Newson <[email protected]> wrote: >>>>>> Also we don't fsync views at all, so if you built the view and then >>>>>> killed couchdb very quickly, the data didn't reach the platters. >>>>>> >>>>>> I'll note that you really, *really*, want to set delayed_commits to >>>>>> false if using couchdb in production. This strongly guarantees that >>>>>> your database updates are preserved in the event of a crash. >>>>>> >>>>>> B. >>>>>> >>>>>> On 20 March 2012 13:51, Jason Smith <[email protected]> wrote: >>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <[email protected]> wrote: >>>>>>>> Hi Alexander, >>>>>>>> >>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote: >>>>>>>> >>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's >>>>>>>>>> designed >>>>>>>>>> that way. You just kill it. >>>>>>>>> >>>>>>>>> With _admin permissions: >>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: >>>>>>>>> application/json" >>>>>>>> >>>>>>>> Excellent, thanks, I'll give this a try. >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <[email protected]> >>>>>>>>> wrote: >>>>>>>>>>> What version are you running? >>>>>>>>>> >>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back. >>>>>>>>> >>>>>>>>> Looks like subversion revision number and a little out of dated. By >>>>>>>>> the way, CouchDB repository had been moved to git not so far a long >>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch? >>>>>>>> >>>>>>>> Yeah, i know it's an old version, I was just curious as to whether >>>>>>>> there was something I could try before rebuilding the server. >>>>>>> >>>>>>> Hi, Martin. I wonder if it is related to this issue? >>>>>>> >>>>>>> CouchDB was deleting .view files if some kinds of errors happened. >>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100% >>>>>>> sure that that is your issue.) >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Iris Couch >>>> >>
