C# Xamarin Replicator Never Leaves Buy State

Mobile
1

I have a pull-only replicator started to download a large database. I attach a change listener to the replicator and the download works just fine UNTIL it is done, then all I see are the following statuses from it (this is on Android) and the [o:] lines are my debug output from the replicator):
[0:] Busy - 120115068 of 120116200
11-28 15:32:32.957 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.782-05:00 Sync 2018-11-28T15:32:32.7826210-05:00 {N8litecore4repl12IncomingBlobE#1682} progress +46419/+0, 0 docs – now 46419 / 46419, 0 docs
11-28 15:32:32.958 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.958-05:00 Sync 2018-11-28T15:32:32.9579380-05:00 {N8litecore4repl12IncomingBlobE#1683} progress +32747/+0, 0 docs – now 32747 / 57999, 0 docs
11-28 15:32:32.958 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.958-05:00 LiteCore 2018-11-28T15:32:32.9583910-05:00 {N8litecore4blip6BLIPIOE#12} Sending frame: AKRES #1783 -UN-, bytes 0–2
11-28 15:32:32.960 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.959-05:00 LiteCore 2018-11-28T15:32:32.9589420-05:00 {N8litecore4blip6BLIPIOE#12} …Wrote 6 bytes to WebSocket (writeable=1)
11-28 15:32:32.961 I/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.960-05:00 Sync 2018-11-28T15:32:32.9606390-05:00 {Repl#4} pushStatus=stopped, pullStatus=busy, dbStatus=busy, progress=120115086/120171321
11-28 15:32:32.961 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.961-05:00 Sync 2018-11-28T15:32:32.9613530-05:00 {Repl#4} progress +1/+0, 1 docs – now 120115086 / 120171321, 18286 docs
11-28 15:32:32.961 I/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.961-05:00 Sync 2018-11-28T15:32:32.9617110-05:00 {Repl#4} activityLevel=busy: connectionState=2
11-28 15:32:32.962 I/CouchbaseLite(11975): [20] 2018-11-28 03:32:32.962-05:00 Sync 2018-11-28T15:32:32.9621640-05:00 (Replicator) [20] Replicator[<* ws://api.redbookfuneraldirectory.com:4984/ebook] is Busy, progress 120115086/120171321
[0:] Busy - 120115068 of 120116200
[0:] Busy - 120115078 of 120171321
11-28 15:32:33.102 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:33.102-05:00 Sync 2018-11-28T15:32:32.9629280-05:00 {N8litecore4repl11IncomingRevE#87} Received revision ‘Directory_cc441900-13ad-e711-80e8-00155d010403’ #1-920519e4466a95734abe22e73a7806e874a41234 (seq ‘18390’)
11-28 15:32:33.103 I/CouchbaseLite(11975): [20] 2018-11-28 03:32:33.103-05:00 Sync 2018-11-28T15:32:33.1035130-05:00 {Pull#9} activityLevel=busy: pendingResponseCount=0, _caughtUp=0, _waitingForChangesCallback=0, _pendingRevMessages=1012, _activeIncomingRevs=100
11-28 15:32:33.105 V/CouchbaseLite(11975): [20] 2018-11-28 03:32:33.104-05:00 LiteCore 2018-11-28T15:32:33.1042490-05:00 {N8litecore4blip6BLIPIOE#12} Received frame: RES #1786 M—, length 16378

So why does the replicator never go to an Idle state and / or why do the bytes never match up?

Also, is there any way to tell from the outset how large the entire download will be?

2

is there any way to tell from the outset how large the entire download will be?

There is not, because it is not calculated at the beginning. The changes are streamed from the server as they are generated (i.e. it doesn’t keep around a list of ‘this user / channel gets these documents’ for every permutation).

So why does the replicator never go to an Idle state and / or why do the bytes never match up?

Well if they bytes don’t match up that is why it will not go into Idle. Idle simply means that the bytes matched up. So as for why the bytes don’t match up…we’ve dealt with this problem before and we haven’t seen it in a while. Are you on the latest version (2.1.2 right now) and if so can you reproduce this in a way that is shareable? If so, then file an issue so that we can look at it.

3

Total download size: that’s fine. It would be cool it a query could be made to get that information as it would allow a developer like me to display a progress bar with accurate “time remaining” information.

Yes, I’m on 2.1.2 and G 2.1.1. Let me see if I can put a repro together for you.

4

You could GET the changes feed in advance, but you’d have to construct it manually and you would take a performance hit because you would be constructing and going through the entire changes feed twice. Check out the Sync Gateway REST API in the docs for more info on the _changes endpoint.

If you succeed in making a repro (it might be hard, we’ve been trying for a long time) then file an issue on the Couchbase Lite .NET repo (although I might move it if I find the issue is somewhere else).

5

Good news! I was able to reproduce it - issue # 1086 tracks it in GitHub…