[CBMA-16] Replication crashes when WIFI connectivity falls back to 3G Created: 10/Oct/11  Updated: 31/Aug/12  Resolved: 31/Aug/12

Status: Resolved
Project: Couchbase Mobile Android
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0

Type: Bug Priority: Major
Reporter: Andreas Klöber Assignee: Farshid Ghods
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CouchDB Version on client: 2.0 Developer Preview
Device: Samsung Galaxy Tab (Android 2.2)

Attachments: Text File couch.log    

 Description   
When a pull replication from the server to the client is going on via WIFI and WIFI connectivity gets lost (i.e. turned of via settings), the fallback to 3G connectivity fails. Instead of falling back to 3G and continuing the replication there is a crash (see attached log output).

The behaviour is reproducable.

 Comments   
Comment by J Chris Anderson [ 10/Oct/11 ]
Filipe,

Is this fixed by your new retry logic? If so, then the fix for mobile will just be a matter of merging your patch.

The logfile has a fairly obvious stacktrace, so it should be easy for you to see if this will fix it.

Chris
Comment by Filipe Manana [ 10/Oct/11 ]
Maybe, There's nothing like trying out the latest source.
Are there more complete logs? I want the full, long, stack traces.
Comment by J Chris Anderson [ 12/Oct/11 ]
I think the request in this ticket, is not so much to get to the bottom of what error might occur when the connection changes modes (as the error we see in Couch may be different depending on exactly when the connection changes). Really what we want is a way to ensure that replication retries automatically anytime it sees that it's stopped making progress.

The preferred way to set up persistant replications (which have more robust retry capabilities) is via the replicator db. The replicator db is documented here:

https://gist.github.com/832610

Essentially you just save documents to the replicator db, that have the same JSON as a replicator POST command. You can then query those documents to see what state the replication is in. There is a config entry which governs the amount of retries that are done: replication_retry_count

As an alternative, assuming that in your current code, the POST to _replicate returns a failure at this point, you can just re-POST when you see that failure.
Comment by J Chris Anderson [ 01/Nov/11 ]
We need to document this and verify that using replicator_db causes the replication to be more tenacious.
Comment by J Chris Anderson [ 02/Nov/11 ]
This will need to be fixed (or given a well-documented work around via the replicator_db by the time of the Android GA release)
Generated at Sat May 18 11:29:35 CDT 2013 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.