couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <>
Subject Re: 1.0.2 regression in continuous replication
Date Sat, 12 Feb 2011 22:22:01 GMT

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"

I want to know the timestamp difference between both.


On Fri, Feb 4, 2011 at 6:26 AM, Dirkjan Ochtman <> 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:
> 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,,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

View raw message