Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YBd9UCq6cxOHoZc29+idV5+XTRjmKjrQEGeZ0-Ard1RdA@mail.gmail.com>
References: 
 <CALKFbxszQyE61rETLDtyu0qCwU_BAbRL-zdTY=n6aRY8JSADzA@mail.gmail.com>
 <CAJ_m3YDNYmrTf2ervpUsgEhNkpvt7c-Y8V6A0hBR6JuH7ZXbog@mail.gmail.com>
 <CALKFbxt_p7S2Bx42npxx8aPSQ-mPqTt0CAbb0DZt5NioGvjoZA@mail.gmail.com>
 <CAN-3CB+QYTKw0Otao8Y17bbEec1_Ricw6wYQawV3TiMDVrHcLg@mail.gmail.com>
 <CAJ_m3YBd9UCq6cxOHoZc29+idV5+XTRjmKjrQEGeZ0-Ard1RdA@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Thu, 25 Aug 2011 10:30:07 +0700
Message-ID: 
 <CAN-3CBKh0KsehEmnx2sz5-3sKxL9P-dEcwsHVJWENN53Gv1Eug@mail.gmail.com>
Subject: Re: Our views keep failing with timeouts until a couchdb restart
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 25, 2011 at 9:55 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> 1. CouchDB has an odd, idiosyncratic, feature where GET queries
>> produce side-effects. From HTTP, there are no side-effects, but as you
>> can see, GETting a view can spawn couches processes and write files to
>> the disk. Perhaps you could add ?stale=ok to all of your queries used
>> in production. To my knowledge, stale=ok guarantees that couchjs will
>> not be involved in servicing that query. This protects your users from
>> seeing map/reduce errors. The down-side is that you must of course
>> query the views yourself to keep them current.
>>
>
> No, couchjs will still be required to service reductions. stale=ok
> just means you don't have to wait for a possibly lengthy view build.

Thanks for the correction.

> Also, "GET's cause side effects" is a bit misleading I think. A GET on
> a view by default tries to return data from something equal to or
> newer than the current database update_seq. If the current view state
> hasn't caught up to the db's update_seq it waits. Classifying this as
> "GET's have side effects" is really like saying "GET to a Rails APP
> causes side effects because you have to wait for the template to
> render."
>
> For those familiar with internals its quite true that if the indexer
> isn't running, a new GET request will trigger an update. But say we
> change that so that view updates are tried every N seconds and a GET
> itself will never trigger an update but might endure a delay of N-1
> seconds before anything starts happening. You'd be hard pressed to say
> that the "GET caused side effects" in that case yet the observable
> behavior is the same: "sometimes it takes a while."

Yes, I use a sloppy definition. Every query has side effects, since
they are logged. But that is a trivial case. So you are right.

At any rate, for all the system administrator knows, a GET query can
create a new .view file and build a 500GB view which fills up the
disk. It's a small detail worth knowing. Day-to-day, it's not that
serious of a threat.

The main point is that you get more robust and more predictable
behavior by using ?stale=ok most of the time, and taking the trouble
to update the views independently. In my projects, I have a change
count and also time duration threshold. If either are exceeded then it
triggers a view refresh on all design documents for that database.

-- 
Iris Couch