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
>>>
>

Reply via email to