couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Eisenmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-691) CouchDB pull replication from HTTPS does not recover after disconnect (hangs)
Date Mon, 15 Mar 2010 15:46:27 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845372#action_12845372
] 

Simon Eisenmann commented on COUCHDB-691:
-----------------------------------------

I just have set up a node running couchdb from 0.11.x branch and can still reproduce the issue
when running pull replication from an SSL address on this couch. So this is not fixed in 0.11.x
branch (0.11.0b923205)

> 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.


Mime
View raw message