You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Paul Joseph Davis (JIRA)" <ji...@apache.org> on 2010/10/09 21:45:07 UTC

[jira] Updated: (COUCHDB-691) CouchDB pull replication from HTTPS does not recover after disconnect (hangs)

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

Paul Joseph Davis updated COUCHDB-691:
--------------------------------------

    Skill Level: Regular Contributors Level (Easy to Medium)

> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.