Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of antpky@gmail.com designates
 74.125.82.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=UesVzt+rWArElsTiJ5Re/63FsxHrsk0i3/OwrKq4+VDOoaCYm8xbD/5PU6TOonGCEG
         3awov3N/lp9XNg4C8MUQYMrHzWMEXexDrxBQH2FXfu6o6866g4hmuRStQd7CMlY+F5hP
         FYdF85MXP5gUr3fgCwnHEaFg1rPMy1p1+AHhs=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=YnMfKTogkd96bW6kiyjip2Sz+JsyYDmAvQn0z@mail.gmail.com>
References: <AANLkTin83KuWd=_0mxfzo_eEBFnxA6C+8pDwehq-RA+C@mail.gmail.com>
	<AANLkTikg5LiW-rVvvOKnGwOrGj14i9vqcCV3031iB30g@mail.gmail.com>
	<AANLkTinE6r5D_C-+heoqjBVYQSbjLOnAQxtJpWwULgnz@mail.gmail.com>
	<AANLkTi=YnMfKTogkd96bW6kiyjip2Sz+JsyYDmAvQn0z@mail.gmail.com>
Date: Wed, 27 Oct 2010 11:22:07 +0100
Message-ID: <AANLkTincjBm2wTBPGg7=8NZWw_ibQdgc0dw5KaQn1=pv@mail.gmail.com>
Subject: Re: Bidirectional replication and new documents
From: Antoine Kurukchi <antpky@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the warm welcome. It's really great that all this
functionality is in the database from the get go. I've got couchdb
running on a couple of machines now and testing how it performs.

I should explain what I'm trying to do. I'm looking at having 1-2
master couchdb servers(use continuous replication here) and then have
multiple(100 or so) client couchdb connecting up and doing a pull
replication. The client database would serve a local application (even
if the client isn't on the net). I was thinking I can do a push
replication from the clients to the server to update. From what has
been said it looks like it would work. Think I will need to be careful
with the id fields.
http://johnpwood.net/2009/06/30/couchdb-databases-and-documents/
suggests that couchdb generated keys won't work well and I think it
won't in my case.

As an alternative I can keep the client databases as read only and
would store the updates in a separate xml file or something. Update
when I know internet is available. It will ensure that no conflicts
can happen between the clients and servers.

Back to figuring out why replication fails when using nginx and
couchdb as a subdirectory.

Thanks again

Antoine

On Tue, Oct 26, 2010 at 8:31 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Tue, Oct 26, 2010 at 11:52, Dave Cottlehuber <dave@muse.net.nz> wrote:
>> On 27 October 2010 03:50, Antoine Kurukchi <antpky@gmail.com> wrote:
>>> Hi All,
>>>
>>> Been reading a lot about couchdb and am really impressed by it. Great
>>> work. I have got a few questions about replication and new documents.
>>
>> Welcome aboard the couch, Antoine.
>>
>>> A lot is mentioned about continuous replication and bidirectional
>>> replication but is it possible to have both features working at the
>>> same time? If it is possible, what happens if there is a disconnection
>>> between the two database servers and are there any pit falls with this
>>> approach?
>
> Bi-directional replication isn't really a "thing" in CouchDB. There's
> been mention recently of adding API sugar to make it easy, but it's
> just two replications. Whether they are continuous or not is
> irrelevant.
>
>>
>> I've had continuous replication running for some time on a small 3-way
>> replicated couch without any issues, in a multi-master mesh (mmm). I
>> believe there may be a timeout - can anybody confirm?
>
> For pull replication, there is no timeout on the source. The source
> will stream changes to the target with empty lines every ten seconds
> as a heartbeat. If the target misses 3 of these it will give up. So
> you have 30 seconds of disconnection before a continuous pull will
> fail. The command to start continuous replication is idempotent,
> though, so it's easy to set up a job that ensures it's always running
> by triggering it every minute or so. In the next release there should
> be a way to tell CouchDB about persistent replication jobs that should
> always be running.
>
> For push replication there is no longpoll on the database changes.
> Instead, you'll only see a failure if one of the individual requests
> totally fails (10 times, with exponential backoff, I think it comes
> out to around 10-15 minutes of disconnection before it'll die).
>
> Looks like Dave answered the rest of your questions. Welcome aboard.
>