[
https://issues.apache.org/jira/browse/COUCHDB-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072757#comment-13072757
]
Hans-D. Böhlau commented on COUCHDB-1231:
-----------------------------------------
We noticed exactly the same effect in our project (using couchdb 1.0.2). Using
filtered replication to regulary update a second database is not stable a soon
as we have some hundreds of documents in the source database. We see the same
timeout entries in our log file.
Requesting the (filtered) changes request manually shows, that it takes more
and more time until the response is delivered - the more the number of
documents (and/or changes) in the database increases.
Maybe it's important: We have a lot of documents with attachments.
Best regards,
Hans
> 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
