http://www.couchbase.com/issues This file is an XML representation of an issue en-us 5.2.4 845 26-12-2012 http://www.couchbase.com/issues/browse/CBMA-16 Couchbase Mobile Android 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). <br/> <br/> The behaviour is reproducable. CouchDB Version on client: 2.0 Developer Preview <br/> Device: Samsung Galaxy Tab (Android 2.2) CBMA-16

Replication crashes when WIFI connectivity falls back to 3G

Bug Major Resolved Won't Fix Farshid Ghods Andreas Klöber Mon, 10 Oct 2011 05:40:04 -0500 Fri, 31 Aug 2012 00:41:16 -0500 Fri, 31 Aug 2012 00:41:16 -0500 2.0 0 0 Filipe,<br/> <br/> Is this fixed by your new retry logic? If so, then the fix for mobile will just be a matter of merging your patch.<br/> <br/> The logfile has a fairly obvious stacktrace, so it should be easy for you to see if this will fix it.<br/> <br/> Chris Maybe, There&#39;s nothing like trying out the latest source. <br/> Are there more complete logs? I want the full, long, stack traces. 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&#39;s stopped making progress. <br/> <br/> 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: <br/> <br/> <a href="https://gist.github.com/832610">https://gist.github.com/832610</a> <br/> <br/> 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 <br/> <br/> 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. <br/> We need to document this and verify that using replicator_db causes the replication to be more tenacious. 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) Rank 10133 Time In Status