Unexpected behaviour for _changes?feed=continuous

Hi,

I have been syncing Sync Gateway with a CouchDB database. Replication seems to works fine in 1.1.0 in both directions but continuous from Sync Gateway to couch to CouchDB fails. It looks like a get with feed=continuous doesn’t behave as expected:

If I use curl to get _changes since 24 it works and I get three revisions

curl https://username:password@mydomain.com/sync_gateway/_changes?since=24

{“results”:[
{“seq”:25,“id”:“network_f4427d9b-f4f4-4491-9025-19dfb7c74cb6”,“changes”:[{“rev”:“1-71a61ad85896a830e8b10117b782dcd3”}]}
,{“seq”:26,“id”:“network_e61ded23-1e79-457d-9ee5-8a3e847248b5”,“changes”:[{“rev”:“1-63868121ec9f91170704094a0b004835”}]}
,{“seq”:27,“id”:“network_56634d91-e813-472c-acbe-59a20a5fc136”,“changes”:[{“rev”:“1-26f1c588d43919088ad0f4f88226e83a”}]}
],
“last_seq”:“27”}

But if I ask for continuous _changes I get an open connection with no content and then a timeout

https://username:password@mydomain.com/sync_gateway/_changes?feed=continuous&style=all_docs&since=24&heartbeat=10000" failed due to error {error,req_timedout}

Am I missing something? Does a _changes request with feed=continuous need extra configuration that CouchDB is not providing?

Thanks

Paul

@paulharter

Is there any infrastructure between CouchBD and Sync Gateway such as a firewall or HTTP reverse proxy?

These can have their own timeouts configured that can interfere with the behaviour of long running HTTP connections.

Andy

Hi Andy,

Yes I’ve got nginx in between. I’ll do a test without.

Thanks for suggesting this.

P