couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Sinclair-Day <>
Subject Re: No heartbeat during filtered replication
Date Fri, 20 Aug 2010 13:46:41 GMT
Just wanted to say I am seeing similar problems when couch is 
under constant or moderate bursts of load.  It seems the change 
filter cannot keep up and the heartbeat is not sent.  In my 
system, on the client side of the change listener, the silence 
is interpreted as a dead socket/read timeout causing the client 
to drop and reestablish the listener feed.  Based on the 
documentation, I would expect a heartbeat to be sent even in 
situations when data were still being processed through the 
filter pipeline.


On 8/20/10 at 5:27 PM, (Jason Smith) wrote:

>Not sure if this is a bug yet so I'm running it by the list.
>I believe couchdb is sometimes not sending a heartbeat during _changes. For
>    /_changes?feed=continuous&filter=ddoc/a_filter&heartbeat=1000&since=0
>If the database has millions of documents but the filter only returns
>a very small number of them, considerable time will pass between
>change updates, possibly well longer than the requested heartbeat. It
>is not easy to tell whether the server or network link is down, or
>whether there is hardcore filtering action.
>I glanced at couch_changes.erl and keep_sending_changes/7 seems to try
>to send the entire change set to date, and only then start sending
>heartbeats after a timeout. Is this a correct assessment? If so I'll
>put it in JIRA.
>It would be nice for an AJAX client to simply specify a heartbeat and
>then setTimeout(die, heartbeat*1.1) or whatever. If the timeout fires
>before data arrives, that situation can be handled.
>Jason Smith
>Couchio Hosting

View raw message