Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Failing sync: manual restart sync #160

Closed
interactiveblueprints opened this Issue · 4 comments

3 participants

@interactiveblueprints

Hello,

While using an instable network it seems TouchDB sometimes is having problems with syncing data. The system reports the sync is done, but not all docs are synced. It's seems that when the connection fails when a document is half synced, the sync is never started.
It's kind of hard to reproduce and we are exploring what really happens. Our typical documents are documents with about 25kb of data and 6mb in _attachments (in +-10 attached .tar files)

What might be a nice feature is a 'panic' button. In case you know there is new data on the server, but it does not sync to the device, invoke this method and TouchDB does a new scan of the DB for changes.
Is that easy to create? Or maybe it's possible to invoke using the current API (stop sync and restart sync just after each other, would that work?)

3 steps we can do together
1- share thoughts about why syncing is instable in an instable network
2- think of ways to collect data about what is exactly going on
3- in the meantime create a simple stupid workaround for the problem, something like hard resetting the sync

Thanks,
Sjoerd de Jong

@snej
Owner

Sounds like issue #101:

If a revision fails to be pushed or pulled, the replicator will process it again the next time it runs, because the checkpoint won't have advanced past it. However, that only happens when the replicator restarts … so in the case of a continuous replication, that can take an indefinitely long time, probably not till the app's next launch.

The workaround is to stop and restart the replication.

@interactiveblueprints

Thanks for your quick response.

The way we start replication is as follows:

        NSArray *repls = [self.database replicateWithURL:[NSURL URLWithString:urlString] exclusively:YES];
        CouchPersistentReplication* pull = [repls objectAtIndex:0];
        pull.continuous = YES;
        CouchPersistentReplication* push = [repls objectAtIndex:1];
        push.continuous = YES;

Your workaround means re-running this code every once in a while? Or is there a way to know a revision failed to push/pull, and apply some logic to only restart when needed?

I think #101 is indeed the core issue. Maybe its good to close this issue and discuss on the #101 thread? Or do you prefer using the mailing list?
I'd be happy to help solving this issue, as to me (and our company) making the replication stupid simple and fool proof is quite important. Our product runs in environments where networks are most often very unreliable. It is the actual reason we chose for CouchDB as a core technology, as it is designed for those environments.

Thanks for your always great support and attention for end users!
Sjoerd de Jong

@interactiveblueprints

I think this also is related to #159 which is about timeout of large attachments. Thanks for the update on the mailinglist https://groups.google.com/forum/?fromgroups=#!topic/mobile-couchbase/kqRFyHQBm1k

@snej
Owner

Your workaround means re-running this code every once in a while? Or is there a way to know a revision failed to push/pull, and apply some logic to only restart when needed?

You can check the error property of the replication to see if any documents failed to copy.

To restart a persistent replication, call -restart on the CouchPersistentReplication objects. (The code you gave just looks up the objects but doesn't do anything do them.)

@jchris jchris closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.