From user-return-15779-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Apr 11 17:44:13 2011 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 87366 invoked from network); 11 Apr 2011 17:44:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Apr 2011 17:44:13 -0000 Received: (qmail 47741 invoked by uid 500); 11 Apr 2011 17:44:11 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 47709 invoked by uid 500); 11 Apr 2011 17:44:11 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 47701 invoked by uid 99); 11 Apr 2011 17:44:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Apr 2011 17:44:11 +0000 X-ASF-Spam-Status: No, hits=3.6 required=5.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of omarshall@facilityone.com designates 216.135.43.146 as permitted sender) Received: from [216.135.43.146] (HELO secure.facilityone.com) (216.135.43.146) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Apr 2011 17:44:06 +0000 Received: from [192.168.10.152] ([216.135.43.146]) (authenticated user omarshall@facilityone.com) by secure.facilityone.com (Kerio Connect 7.1.3) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Mon, 11 Apr 2011 13:43:44 -0400 Message-ID: <4DA33DBA.1070500@facilityone.com> Date: Mon, 11 Apr 2011 13:43:22 -0400 From: Owen Marshall User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: user@couchdb.apache.org CC: Mage Subject: Re: replication References: <4DA1A9CC.4070407@mage.hu> <4DA32E5C.6090100@facilityone.com> <4DA33815.5000303@mage.hu> In-Reply-To: <4DA33815.5000303@mage.hu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA50DDC0D8C133248454210BD" --------------enigA50DDC0D8C133248454210BD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/11/2011 01:19 PM, Mage wrote: > On 04/11/2011 06:37 PM, Owen Marshall wrote: >> >> IIRC network errors won't kill replication -- it will merely keep tryi= ng >> until the connection is re-established and then come back into sync. B= ut >> I could be wrong here... > I pulled out the ethernet cable from the laptop for about 5 minutes the= n > plugged back and continous replication didn't get restored. >=20 > However calling some cronjob once per minute seems to be acceptable. > Until a new vesion comes out with permanent replication feature. I guess I was wrong. Strange -- I was pretty sure that I was right. I haven't poked the replication in a while, but it is possible that retries back off when replication fails. Hopefully someone more knowledgeable can expand on this. >> Are you *sure*? Think very carefully here. >> >> IMO, conflicts should not be seen as "bad". Instead, they should be se= en >> as an intermediate state that should be resolved as soon as possible. >> >> If you design your app to watch for _conflicts: true, and handle the >> conflicts in a way that makes sense to your application, you will be >> much happier -- not only will your application "just work" without you= r >> pager vibrating 24x7, but you may find that your app will be able to d= o >> things you hadn't thought of before. > In the meantime I played a bit with CouchDB and realized that conflicts= > happen when: I start working with a document on node A =3D> I modify an= d > save the same document on node B =3D> Replication happens =3D> I try to= save > the original object on node A. >=20 > So conflict can happen not during the replication but on save if I am r= ight. Conflicts will occur any time that edits diverge. It's possible for conflicts to occur on replication: * Nodes B & C pull document 1 from node A * Nodes B & C make & save separate changes to document 1 * Replication occurs, either between B & C, or from one node to A and then to the other. Note that continuous replication reduces the time window for conflicts to occur, but it will not eliminate them. Thus you must treat conflicts not as an "exceptional case" but as an expected state. > The strange thing is, at least for me, that if I modify a document on > node A *when there is no replication* for example if the link is dead > then I modify the same document on node B and after that I start > replication then the later version of the document wins and the other > version becomes "lost" without any trace. It doesn't even stays there a= s > previous version. At least as I experienced so far. I might missed > something. A basic `GET /db/document` will not provide any indication that a conflict has occurred. It's up to you to ask. See here for more: http://wiki.apache.org/couchdb/Replication_and_conflicts --=20 Owen Marshall FacilityONE omarshall@facilityone.com | (502) 805-2126 --------------enigA50DDC0D8C133248454210BD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2jPb0ACgkQcoY1cxL6GH19mwCfZj69Fv6nzZnMMeWCpqCBsBwW ZiUAn2ndyVBus05e21xKDzlEXG+ww264 =/jvp -----END PGP SIGNATURE----- --------------enigA50DDC0D8C133248454210BD--