couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: Strategy for reliable _changes feed workers
Date Mon, 05 Mar 2012 22:20:54 GMT

On Monday, 5 March 2012 at 21:32, Robert Newson wrote:

> I'd urge caution here. The _changes feed allows the replicator to
> avoid reprocessing updates that the target has already seen but,
> crucially, replication is not broken if the feed includes old updates.
> In BigCouch, and hence a future version of CouchDB, the changes feed
> can sometimes contain rows from before the since= value, in the case
> of failover to a different replica of a shard.

+1 we've seen this exact issue in one of our projects 
> Clearly, in BigCouch, you could not depend on the changes feed to
> ensure you process an item exactly once, so I suggest its a bad
> practice to assume the same of CouchDB. Instead, I would create a view
> that includes unprocessed items. Once processed (whatever that
> entails), update the document to indicate it has been processed. This
> will work everywhere.

There's an issue with this in that you have an eventually consistent database and you require
a consistent update (read my write) on a cluster. Yes you'd need to be a bit unlucky to have
this happen but the race condition isn't that impossible to meet in a big enough system. 

Thats especially true if "workers" are replicating from the central database, writing that
update to the local DB and then replicating back, resulting in conflicts, confusion and horror.
If your workers do something that isn't idempotent (e.g. launch a rocket) you kind of need
a handshake between the different clients, it's not enough to just take an unprocessed document,
you have to make sure that no one else has taken it, too. In the case of replicating workers
you have a consistent winner and a set of conflicts. If your change to the database is the
winner you do the work, if it's a conflict you don't.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message