couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: _changes feed continuous mode hangs up after 90 seconds
Date Thu, 23 Jun 2011 02:06:00 GMT
On Thu, Jun 23, 2011 at 6:52 AM, Randall Leeds <> wrote:
> On Wed, Jun 22, 2011 at 16:27, Jens Alfke <> wrote:
>> I’m guessing that, contrary to the docs, there is a default timeout in
>> continuous mode, and I’ll have to add something like “&timeout=9999999999”
>> to the URL to defeat this?
>> (This is the 1.1.1 CouchBase Server Community Edition, on Mac OS X 10.6.7.)
>> —Jens
>> [1]
> You don't want to have an insanely long timeout because then, in the
> absence of changes, it's impossible to detect that the receiver is
> gone.
> You should use the heartbeat parameter instead and make sure whatever
> client code you use can tolerate the blank new lines.

TCP keepalive allows insanely long timeouts. It does exactly what
couch heartbeats do: periodic out-of-band no-op transmissions to
confirm the connection.

However, Couch heartbeats are way more convenient and portable and
predictable. So in other words, by all means, use heartbeat!

I am satisfied with a _changes follower I rewrote in NodeJS: IMHO it has a decent error
detection and handling model.

I suggest the following technique:

1. Keep track of what `seq` you've seen, perhaps initially 0
2. Query _changes, with a heartbeat, and &seen=$seq_Ive_seen
3. Set a timer for heartbeat * 1.1, or heartbeat + 5 seconds, or similar
4 .Keep a *second* timer, the change deadline. Set this relatively long.
5. Every time you receive data, reset the heartbeat timer
6. If the heartbeat timer fires, stop your query, go to step 2
7. If the deadline timer fires, stop your query, alert a human. Go to
step 2 (or maybe exit)

Also note: filtered queries will *not* send heartbeats until all docs
have been processed. CouchDB will miss its heartbeat deadline if it
has many documents which all fail the filter. If that is a problem,
use TCP keepalive or  a client-side filter.

The deadline timer is an important sentry. The deadline requires a
*change* (not a heartbeat: a proper change) within some time. Say to
yourself "There is *no possible way* this much time could elapse
without a change." and set the deadline to "that much time."

The deadline timer will catch several classes of errors:

* DNS change is sending you to the wrong couch!
* Programmer error is sending you to the staging server!
* You have a bug in your filter function
* You have a bug in your validate_doc_update function
* Client bug: clients can't access couch, or old clients are creating
invalid docs
* Authentication errors, e.g. you forgot to restore _users from backup

Many of these errors are something an operator or admin would want to
know about. It's not bulletproof but it can help.

Iris Couch

View raw message