couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Replication and new user questions
Date Wed, 26 Aug 2009 20:50:10 GMT
On Aug 26, 2009, at 4:33 PM, Blair Zajac wrote:

> Thanks for the quick reply, I appreciate it.

No problem, glad to help!

> I neglected to mention that we're running trunk r807360.

Ok, the fix I was talking about showed up in r807477, so you missed it  
by a couple of hours.

> Is there a wiki or place that CouchDB keeps its design documents for  
> new features for people to learn about, e.g. a ticket or checked  
> into svn as a text file?

Nothing quite so organized as that, no.  The  
list is the one place where you're guaranteed to see all discussion of  
new features.

>>> 3) How does continuous replication deal with network outages, say  
>>> if a link goes down between the Los Angeles and Bristol data  
>>> centers?  Does CouchDB deal with a hanging TCP connection ok?
>> CouchDB retries requests using a timeout that doubles with every  
>> failure.  It does this for about 5 minutes, then gives up.
> That sounds like it would still then require an external script to  
> start the replication again.
> In fact, our Bristol office had a power outage earlier today that  
> lasted over an hour, so to write a script to kick start replication  
> again would be inconvenient.

Hmm, I can sympathize.  I'll see what we can do to distinguish between  
bad replication requests (where we want to give up immediately and  
inform the client) and extended outages (which are a common use case  
for CouchDB replication and something we want to handle well). I think  
it should be possible.

>>> 5) I wrote the following Bourne shell script and after running it  
>>> for an hour, it consumes 100% of a CPU.  This is even after  
>>> stopping the shell script and compacting both databases.  What  
>>> would explain this behavior?
>> I couldn't quite get that script to work ($HOST2 was undefined, and  
>> then something else failed), but can you try it again with a fresh  
>> checkout?  I fixed a bug last night that could very well have  
>> caused this.  Best,
> I've attached the latest version of the script which I just ran.
> After multiple runs of the script and letting it run indefinitely,  
> I've noticed that something will fail in CouchDB and the script will  
> either wait forever for the key to appear in the other database or a  
> PUT will fail.
> The last error I got was that using curl and PUT returned nothing  
> and this error in my shell.  It scrolled past the top, so I don't  
> have the top of the stack:


Yep, the changes_loop_dies error is consistent with the bug that I  
fixed in r807477.  If you have a chance to svn up I think you'll see  
this bug disappear.  Best,


View raw message