Dirkjan, What's the time delta between the moment the replication started and the moment you get the changes_timeout error? Is it a delta of about 30 seconds?
You can check when the replication started by inspecting the log file for a line like this: [Sat, 12 Feb 2011 22:16:10 GMT] [info] [<0.108.0>] starting new replication "bae147260ef23b1d062188e6838d68d7" at <0.192.0> The relevant error message in your log is the third one: "[Tue, 01 Feb 2011 06:23:54 GMT] [error] [<0.3701.3>] changes loop timeout, no data received from http://10.8.0.1:5984/efp/"; I want to know the timestamp difference between both. regards, On Fri, Feb 4, 2011 at 6:26 AM, Dirkjan Ochtman <[email protected]> wrote: > Hi everyone, > > I asked about this a bit on IRC, but we decided that this might be > better on the mailing list. > > At work, we use CouchDB continuous replication for some important > streams, from a server in a data center somewhere to the servers in > our office, over OpenVPN. This was partly done because the > consumer-grade internet in our office (hey, it's a startup) is a > little flaky at times. This used to work fine; we had a script to > restart the replication if it failed, but that only happened once in a > week or a few weeks. > > However, since installing 1.0.2 on Monday, we see our continuous > replication failing much more often, like 3-5 times per day. It seems > to fail complaining about some timeout, here's a trace: > http://dirkjan.ochtman.nl/files/repl-fail.log. > > Is anyone seeing similar behavior? Are there any changes in CouchDB > between 1.0.1 and 1.0.2 that could have caused this? We're running > fairly standard Linux boxes, not much else changed on Monday. > > Cheers, > > Dirkjan > -- Filipe David Manana, [email protected], [email protected] "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
