Unexpected behaviour for _changes?feed=continuous

Mobile Sync Gateway
1

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

2

@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

3

Hi Andy,

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

Thanks for suggesting this.

P