On Thu, Jul 29, 2010 at 12:15 AM, Randall Leeds <[email protected]> wrote: > It seems like with your deployment you would rather be using > continuous replication since your data is server-side and your servers > are generally connected. It might be harder to generate conflicts in a > test scenario this way because you have to "beat" the replication to > the other copy.
I realize that, however in an attempt to make the test rigorous as if the node just came back after a crash, where actually conflicts arrose while it was down, I started replicating just after the conflicting saves were done, to simulate that. But come to think of it, I don't think there are too many solutions or even if it is possible at all to have one node resolve all the conflicts it gets of being down for an hour for example, quickly. It is simply impossible given the other nodes have accumulated substantial backlog. Given that, and in view of the fault tolerance CouchDB provides, does one need to check if a node wa brought up, and wait for all the changes to have been processed , or is it something more in my resolution code, in which I have to wait until the current chunk of resolutions is done? > > The result of using continuous replication would mean that you will > get update conflicts more often than conflicting revisions. Your > client can handle this by fetching the document and deciding (based on > the timestamp) whether it should clobber the current value. I am going to test this now (which is actually the healthy production state of my setup) but as I said, you cannot guarantee replication will work all the time, as we're dealing with a "cluster of unreliable commodity hardware" (tm) :-) I'm starting to fear the rabbit hole deepens....=) Any ideas how to approach this if my approach is even half wrong? -Sivan
