Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates
 209.85.161.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=vaEEefBQ+PzkYVeY+jdkfVeTkwhkFvWEhUdeEq7/XPfwbcqOWKYNkgrovZHwJc10m3
         rer5UML5RncUuqxGBvH9bWHFD8KkPCQGPXYpSKd4X+AjqAO1Sua8L89TBv5yy69gt/oS
         MEfso6AoDQoZl6EPwbSV8btdskSjcKhsBID5s=
MIME-Version: 1.0
Sender: fdmanana@gmail.com
In-Reply-To: <AANLkTinUkS17CuKLjTs53OQrDk7uBY1k62G84mtRcSNU@mail.gmail.com>
References: <AANLkTinUkS17CuKLjTs53OQrDk7uBY1k62G84mtRcSNU@mail.gmail.com>
Date: Sat, 12 Feb 2011 14:22:01 -0800
Message-ID: <AANLkTikH29S53yxRXoCFbc+25f7Zpi8Dfvv1rCr0RGaD@mail.gmail.com>
Subject: Re: 1.0.2 regression in continuous replication
From: Filipe David Manana <fdmanana@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <dirkjan@ochtman.nl> 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
>


--=20
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org

"Reasonable men adapt themselves to the world.
=C2=A0Unreasonable men adapt the world to themselves.
=C2=A0That's why all progress depends on unreasonable men."