couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Clark <jcl...@maf.org>
Subject Replication consistently fails
Date Mon, 10 Mar 2014 18:06:07 GMT
Hi,
I’m trying to figure out why my app is having difficulty replicating, and hoping someone
here can help.

I have a couchdb 1.4 server setup behind an Apache reverse proxy. We’re only allowing HTTPS
connections to the Apache server, and couchdb user credentials are needed to access any db.
I’m inside a corporate network, but have verified with sysadmins that the appropriate (documented)
ports are open for CouchDB replication to happen. The couchdb server in question is in a DMZ.
Please let me know if that’s enough info.

While my laptop is on my corporate (public) wi-fi network, I’m trying to replicate a db
from my server (in our DMZ) with this post to _replicate, but it consistently times out:

{"source":"https://username:password@estante.maflt.org/dbname","target":"eeb"}

While I’m external to our network, the replication succeeds without problem.

Using a REST client inside my corporate network, I get no response and it eventually times
out. The Erlang log shows this message:

Replicator, request GET to "https://username:*****@estante.maflt.org/dbname/_changes?feed=normal&style=all_docs&since=0&heartbeat=10000"
failed due to error timeout

We’ve scoured logs for errors or issues related to connectivity from our public LAN and
our DMZ, and nothing appears to be blocking our connection. Regular HTTP/HTTPS can go through
just fine. I can access Futon just fine on the server, and the server pull can replicate into
itself just fine.

Could someone point me in the right direction to figure out why replication seems to fail
so consistently like this? Are there other ports we need to be looking at? Other protocols
being used? Is there a flaw in my replication request? Is there some network config I need
to have our sysadmin look at that could be preventing this?

As far as I can tell though, the behavior seems to indicate that the document is not fully
getting posted to the localhost’s _replicate method.

Thank you,
Jay Clark
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message