Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 21 Jul 2011 15:19:57 +0000 (UTC)
From: "Robert Newson (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <479995383.11632.1311261597733.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1025535273.11616.1311261237883.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (COUCHDB-1231) Replication times out
 sporadically
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069020#comment-13069020 ] 

Robert Newson commented on COUCHDB-1231:
----------------------------------------

The 'Reason for termination ==  changes_timeout' points at the internal use of the timer module rather than anything network related. I took a quick look at how the time is set (and cancelled) and it looks ok. It does appear to be reset if a heartbeat is received even if there's a filter.

> Replication times out sporadically 
> -----------------------------------
>
>                 Key: COUCHDB-1231
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1231
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 1.0.2, 1.0.3
>         Environment: CentOS 5.6 64 bit, XFS HDD drive. Spidermonkey 1.9.2 or 1.7
>            Reporter: Alex Markham
>              Labels: changes, replication, timeout
>         Attachments: Couchdb Filtered replication source timeout .txt, Couchdb Filtered replication target timeout .txt
>
>
> We have a setup replicating 7 databases from a master to slave. 2 databases use filters. One of these databases (the infrequently updated one) is failing replication. We have a cronjob to poll replication once per minute, and these stack traces appear often in the logs.
> The network is a gigabit lan, or 2 vms on the same host (same result seen on both).
> The replication job is called by sshing into the target and then curling the source database to localhost
> Source -> Target
>  ssh TargetServer 'curl -sX POST -H "content-type:application/json" http://localhost:5984/_replicate -d {"source":"http://SourceServer:5984/DataBase","target":"DataBase","continuous":true,"filter":"productionfilter/notProcessingJob"}'
> changes_timeout is not defined in the ini files.
> Logs attached for stack traces on the source couch and the target couch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira