Document not syncing when .save(doc) is called in quick succession


Currently have an app which needs to update a quantity field in a document whenever an increment/decrement button is clicked. When these buttons are clicked in quick succession (I am talking less than .5 of a second apart), the amount is not correctly synced to the server BUT it is updated locally.

Here is the error log that appears every time I experience this problem:


07-26 09:22:22.173 6904-6904/net.ordercheck_in D/InvoiceRepositoryImpl: Replacing the dictionary with 1 for 1
07-26 09:22:22.183 6904-6922/net.ordercheck_in I/LiteCoreJNI: [NATIVE] C4Replicator.statusChangedCallback() repl -> 0x0xb82f9ce0 status -> 4
07-26 09:22:22.233 6904-6904/net.ordercheck_in D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
07-26 09:22:22.293 6904-6904/net.ordercheck_in D/InvoiceRepositoryImpl: Replacing the dictionary with 2 for 2
07-26 09:22:22.383 6904-6923/net.ordercheck_in I/LiteCoreJNI: [NATIVE] C4Replicator.statusChangedCallback() repl -> 0x0xb82f9ce0 status -> 4
07-26 09:22:22.413 6904-6925/net.ordercheck_in E/LiteCore [Sync]: {Push#1}==> N8litecore4repl6PusherE ->
{Push#1} Proposed rev ‘user.23200’ #3-b9788eae1f7594ec605e9a2442fe3ef2a95d6182 (ancestor 1-b8a61b7725d8dee58ccf1bd35bc8fd22) rejected with status 409
07-26 09:22:22.413 6904-6922/net.ordercheck_in I/LiteCoreJNI: [NATIVE] C4Replicator.documentErrorCallback() repl -> 0x0xb82f9ce0, pushing, rejected by server
07-26 09:22:22.413 6904-6922/net.ordercheck_in E/C4Replicator: documentErrorCallback() handle -> 3090128096, pushing -> true, docID -> user.23200, domain -> 6, code -> 409, internalInfo -> 1000, trans -> false
07-26 09:22:22.503 6904-6925/net.ordercheck_in I/LiteCoreJNI: [NATIVE] C4Replicator.statusChangedCallback() repl -> 0x0xb82f9ce0 status -> 3
07-26 09:22:22.513 6904-6904/net.ordercheck_in E/Replication Comp Log: Schedular Completed
07-26 09:22:22.583 6904-6924/net.ordercheck_in I/LiteCoreJNI: [NATIVE] C4Replicator.statusChangedCallback() repl -> 0x0xb82f9ce0 status -> 3
07-26 09:22:22.583 6904-6904/net.ordercheck_in E/Replication Comp Log: Schedular Completed

Anyone who has experienced updating a document on button press, your input would be appreciated.

If you see this log you can see that there is conflict in the document hence the document is not getting synced on server as the server doesn’t allow conflict.

CBL 2 doesn’t allow conflicts either, so that’s not why the server’s rejecting it. This may be a problem in the replicator logic.

@baileyp: How are you replicating? Do you have a continuous replication to the server that’s active while this is going on? You’re not creating multiple replications, are you?

Here is my replicator function, and nope, only one is running at a time. This only happens when the method is called in very quick succession. All other saves work fine.

   private fun startLiveRequests()
    Log.d(TAG, "Replication started...")

    val mSyncGatewayEndpoint = "ws://hiddenURL:4984/database/"
    var url: URI? = null
        url = URI(mSyncGatewayEndpoint)
    catch (e: URISyntaxException)

    val config = ReplicatorConfiguration(database, URLEndpoint(url!!))
    config.replicatorType = ReplicatorConfiguration.ReplicatorType.PUSH_AND_PULL
    config.isContinuous = true
    //password is in the syncgateway config file, using.... because its already in there
    config.authenticator = BasicAuthenticator("user", "password")

    val replicator = Replicator(config)
    replicator.addChangeListener { change ->
        if (change.replicator.status.activityLevel == Replicator.ActivityLevel.IDLE)
            Log.e("Replication Comp Log", "Schedular Completed")
        if (change.replicator.status.activityLevel == Replicator.ActivityLevel.STOPPED || change.replicator.status.activityLevel == Replicator.ActivityLevel.OFFLINE)
           // close()
            Log.e("Rep schedular  Log", "ReplicationTag Stopped")

Hm. We had some bugs during development with rapid-fire updates to the same document during replication, but those were all fixed. This might be another manifestation…

As a workaround, avoid saving the document that often. Make the incremental changes in the in-memory Document, but don’t save it until the user presses Done or goes to another screen. If that doesn’t fit your UI, at least use a timer so you don’t save until it’s been a few seconds until the last change.

I need to have a constant replication opened in order to show my users new documents that have been posted. If I am making changes to the document how do I prevent it from syncing to the server when a change has been made to the local database (with a constant replication active)?

Also, if this turns out to be a bug in sync gateway-way, will this be fixed? This is an issue for us.

Changes to a Document aren’t saved to the database until you save the document. You can change a property value every time the button is clicked; just don’t save the document immediately.

How can we save it to the local database but prevent sync gateway from trying to sync the changes to the live server when we have a constant pull/push replication enabled?

I was able to come up with a solution by calling replicator.start() in the activity destroy method, but after X amount of syncs, the app crashes and gives me the following log:

08-01 11:41:19.983 16951-17038/ A/libc: heap corruption detected by dlmalloc_real
Fatal signal 6 (SIGABRT), code -6 in tid 17038 (RenderThread)

Guessing there is some sort of memory leak in Couchbase 2.0? Seen a couple of reports on the github page for the same thing.

I think you mean “…but prevent CBL’s replicator from pushing the changes to SG”?

You can’t in 2.0. In the next release after 2.1 we’re adding “push filters”, which will let you control which documents get pushed.

after X amount of syncs, the app crashes and gives me the following log

Is this .NET? @borrrden has been grumbling about a heap issue; I’m not sure if he’s resolved it yet.

This heap corruption happens on my android client randomly. Sometimes after the first sync to the server and sometimes after several syncs have completed.

This is my exact issue:

If we didn’t have this problem our current solution for the saving documents would be working fine for what we need

I compiled the source code from the github page and used that, it seems to have fixed my continuous replication error. The heap corruption still happens when trying to manually invoke the replicator though.

When will V2.1 be released for android?

@baileyp Could you solve this problem? I am using V2.1 but I am experiencing the same problems?

Please file an issue on Github, including client logs.