incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sivan Greenberg <>
Subject Re: beam CPU hog
Date Thu, 29 Jul 2010 10:22:32 GMT
On Thu, Jul 29, 2010 at 12:15 AM, Randall Leeds <> 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?


View raw message