On Thu, Jun 23, 2011 at 6:52 AM, Randall Leeds <[email protected]> wrote: > On Wed, Jun 22, 2011 at 16:27, Jens Alfke <[email protected]> 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] http://wiki.apache.org/couchdb/HTTP_database_API#Changes > > 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: https://github.com/iriscouch/follow. 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
