couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Our views keep failing with timeouts until a couchdb restart
Date Thu, 25 Aug 2011 03:30:07 GMT
On Thu, Aug 25, 2011 at 9:55 AM, Paul Davis <> 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

View raw message