[
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
