incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <bl...@orcaware.com>
Subject Re: Replication and new user questions
Date Wed, 26 Aug 2009 22:03:13 GMT
Adam Kocoloski wrote:
> 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.

I'm trying it now.

>> 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 dev@couchdb.apache.org 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.

That would be great, thank you.

>>>> 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:
> 
> <snip>
> 
> 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,

OK.  Will try.

Regards,
Blair


Mime
View raw message