Pull Replication still getting a lot of changed() event straight after one-shot replication

Mobile
,
1

Hi,

Let me describe the current scenario. I’m using couchbase for android, added the libraries as submodules in my project.

For my replication process:

  1. Create a one-shot replicator, attach replication observer, check for STOPPED status
  2. STOPPED status detected, tear down pull replicator
  3. Recreate a new replicator that is continuous, attach replication observer

Observation
So far, every time i do this (fresh application requiring an initial one-shot sync), i can see that after step 3 above, i can see a lot of changed(Replication.ChangeEvent event) event in the replication observer, where Replication.getChangesCount() that is not 0, Replication.getCompletedChangesCount() that is always zero, Database.getLastSequenceNumber() looks correct and constant (i.e. 15900, unchanged through the change() event).

If i shut my application and restart my application, this behaviour will continue, where the initial sync is fast (it did it before) but continuous replication will be very active.

If i leave the application running and let the flurry of change events pass (for my database that is about 15k documents, it takes about 3-5minutes), eventually, changed(Replication.ChangeEvent event) will stabilize, where i don’t see any more of these flurries of change events anymore. Even restarting my application, it goes through one-shot fast and continuous replication after is normal.

So i’m curious what the cause of this behaviour is. Any ideas?

Cheers!

2

It sounds like the checkpoints on local and remote got mismatched. When this happens, the replication process will start over from the beginning. As part of the algorithm for pull, the target will ask the source for a list of changes and examine them to see if it already has any. If it does it will skip them and move to the next. That’s probably what you are seeing in your flurry. Once it is caught up correctly and the checkpoints are in sync then from that point it only needs to get the changes since the last time it was updated and not from the beginning anymore.

3

Thanks for that explanation, much appreciated!

Is this the expected behaviour in my scenario though? Having replicated one-shot and follow that up immediately with a continuous replicator, the local and remote checkpoint should already be sync i would have thought? I tested this multiple times, ensuring no one is touching the database while i test on the replicators.

4

A continuous and one shot will be considered two different replications actually for checkpoint purposes.

5

In that case, the behaviours makes sense. Thanks for that!

6

One more thing: if this is the case (where one shot and continuous replication have different checkpoints), then its not advisable to have an application that runs a oneshot replication first, then tear it down and run continuous replication?

7

Yes; the behavior will be correct, but there will be extra overhead because the second replication will have to scan through the entire changes feed from the server to catch up.

This isn’t ideal, since there are valid use cases for using both one-shot and continuous replications to the same server. I think it’s something we can fix in the future.