couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filipe Manana (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (COUCHDB-691) CouchDB pull replication from HTTPS does not recover after disconnect (hangs)
Date Tue, 28 Jun 2011 14:33:17 GMT

     [ https://issues.apache.org/jira/browse/COUCHDB-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Filipe Manana closed COUCHDB-691.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 1.0.2
                   1.1
         Assignee: Filipe Manana

Thanks Simon. This should have been fixed in 1.0.2 and 1.1.0

> CouchDB pull replication from HTTPS does not recover after disconnect (hangs)
> -----------------------------------------------------------------------------
>
>                 Key: COUCHDB-691
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-691
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 0.10.1
>         Environment: CouchDB 0.10.1 on Ubuntu 9.10 64bit with Nginx 0.7.62. 
>            Reporter: Simon Eisenmann
>            Assignee: Filipe Manana
>             Fix For: 1.1, 1.0.2
>
>
> have several CouchDB instances replicating through untrusted network
> space. Thus these instances are behind a Nginx SSL-Proxy. Everything
> works fine though when for whatever reason one of the connection breaks
> then this pull replication never recovers. Even restarting the
> replication job does not have any effect despite not giving an error.
> Also in Futon the replication jobs are still reported as running (they
> never go away).
> I just have set up a local test environment with just two nodes
> replicating to each other. One of the nodes is behind Nginx with SSL,
> and the other is directly reachable unencrypted. When restarting the
> unencrypted instance the pull replication on the other Couch recovers
> like a charm and and things are in sync quickly again. Not so when i
> restart the instance behind HTTPS. This replication never results in any
> action again until the instance doing the pull replication is restarted.
> After a couple bit of debugging i found that it seems like the _changes
> feed is never again requested from the just restarted instance. As soon
> as i restart the instance i get the following entry in the Nginx log:
> 10.1.1.201 - - [10/Mar/2010:17:40:50 +0100]
> "GET /database_1/_changes?style=all_docs&heartbeat=10000&since=3135&feed=continuous
HTTP/1.1" 200 408 "-" "CouchDB/0.10.1"
> This means the long running connection has just finished (this was the
> former working replication request). Afterwards i would suspect the
> Couch to start up such a request again, though this never happens.

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

        

Mime
View raw message