couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans-D. Böhlau (JIRA) <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1231) Replication times out sporadically
Date Fri, 29 Jul 2011 09:37:09 GMT

    [ 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

       

Mime
View raw message