Replication, LiveQuery & Sync Gateway

77 views
Skip to first unread message

Steve

unread,
Dec 12, 2014, 9:27:07 AM12/12/14
to mobile-c...@googlegroups.com
Am I right to assume if replication is setup as continuous in an app this results in a permanent connection between the app and Sync Gateway?

If my assumption above is right, is a LiveQuery akin to having a permanent connection between the app and Sync Gateway, much like replication? Actually if my assumption is right it raises another question, what happens if the app loses network connectivity or becomes inactive (i.e. the user switches to another app)? My main concern is whether to use continuous replication or not and the resources required to handle X number of users all using continuous replication.

For pull replication, at any moment in time, does it know the total number of changes between the Couchbase Server bucket and the Couchbase Lite database? For example, if the Couchbase Server bucket has 100 documents and Couchbase Lite has 30, does the pull replication object know there are 70 (100-30) documents to sync? Or does it only determine this over time (e.g. at time1 there are 10 documents to sync, at time2 there are 45 and finally at time3 there are 70 documents to sync)?

Maybe I am thinking about replication too much...






Jens Alfke

unread,
Dec 12, 2014, 11:39:38 AM12/12/14
to mobile-c...@googlegroups.com
On Dec 12, 2014, at 6:27 AM, Steve <s.ande...@gmail.com> wrote:

Am I right to assume if replication is setup as continuous in an app this results in a permanent connection between the app and Sync Gateway?

By default, yes: the app will open a socket to the gateway (either WebSocket or long-poll HTTP). It's possible to use polling instead, which doesn't leave a socket open but increases latency.

This does mean that scaling a sync deployment involves managing large numbers of open sockets. Fortunately that's a pretty common server requirement these days (thanks to the "real-time web") so the techniques are pretty well-known. (Google [c10k problem].) The Sync Gateway is written in a highly parallel language (Go) that can handle lots of threads, and the gateway scales horizontally so you can always add more nodes.

If my assumption above is right, is a LiveQuery akin to having a permanent connection between the app and Sync Gateway, much like replication?

No, LiveQuery has nothing to do with replication, it's entirely local. All it does is watch for local database changes, and re-run the query after each one, posting a notification if the results change.

Actually if my assumption is right it raises another question, what happens if the app loses network connectivity or becomes inactive (i.e. the user switches to another app)?

The replicator takes care of all of that. It attempts to reconnect when possible. It closes the connection when the app backgrounds and restores it when it returns to the foreground.

For pull replication, at any moment in time, does it know the total number of changes between the Couchbase Server bucket and the Couchbase Lite database? For example, if the Couchbase Server bucket has 100 documents and Couchbase Lite has 30, does the pull replication object know there are 70 (100-30) documents to sync? Or does it only determine this over time (e.g. at time1 there are 10 documents to sync, at time2 there are 45 and finally at time3 there are 70 documents to sync)?

Basically yes. You can read about the algorithm if you like.

—Jens
Reply all
Reply to author
Forward
0 new messages