I am using the replicator in Couchbase Lite 2.5.1 on iOS with Objective C.
It all seems to work fine for the most part but recently it has started failing and it gives the following error in the Xcode log
CouchbaseLite Replicator ERROR: {DBWorker#3}==> litecore::repl::DBWorker ->wss://{sync-gateway-address}
CouchbaseLite Replicator ERROR: {DBWorker#3} Threw C++ exception: properties excessively large
I can’t seem to find any information on this error message, and there isn’t much that seems to help it.
Restarting app has no effect.
Restating sync-gateway has no effect.
Any help on this issue would be greatly appreciated.
Since you mentioned that this used to work and assuming you have made no changes to your app code or environment since, it may be worthwhile looking into docs that may have been recently added - maybe something in the docs is triggering the crash.
This is the full error from the console logging. Does the file based logging provide more detail?
Yeah, I strongly suspect that it is something in the docs that is triggering the crash, but what would it be? My guess would be that there were a large number of revisions?
Can you give me any insight into what this error means? Or what could be setting it off? Maybe I could dig a little deeper if I knew what it meant?
@jens Do you know how the properties could get too large? I know the direct reason why the error happens but not the reason for getting into that situation.
What exactly is it referring to when it says that the “properties are too large”?
Is this just the document size itself? Or is it the document properties? If it is the latter, as far as I know, I don’t at any stage do any writing to the document properties?
@Michael_McAdam, can you reproduce this bug when running your app in Xcode? If so, please set a breakpoint on exceptions (use the “+” button at the bottom of the breakpoint navigator) and when this specific exception happens, capture a backtrace by typing “bt” at the debugger console.
I don’t think that there is a huge change in the number of documents between when it fails and when it succeeds.
I am simply creating a replicator object: _replicator = [[CBLReplicator alloc] initWithConfig:replConfig];
And then running with: [_replicator start];
I don’t know if that helps to answer your question.
My only thought is that due to how the program works the documents get updated relatively regularly. It seems to be an issue that only lasts for a little while so my thought is this. (Based off a very limited understanding on how all of this works). The document properties get very large because there are a large number of revisions and when those are attempted to be pushed it fails. As time goes on, CBL automatically purges the older revisions and eventually reduces the size so that it can be synced. Again, I’m just spitballing here cause I don’t really know how all of this works.
Hmmm… CBL is only supposed to keep track of the last 20 revisions. Even if it were keeping more, it would take a lot of revisions to trigger this; something like 2,000. Is it possible your app modifies a single document this many times between replications?
Your guess was correct, Michael — I’ve written a unit test that recreates the error by pushing a document, modifying it 5000 times, then pushing it again. Now to figure out a fix…
I’ve fixed the bug; I don’t know whether the fix will make it into the upcoming 2.7 release or be delayed to 2.7.1 or something.
The workaround is to not make so many (2,000+) local changes between syncs. That’s kind of a lot! Consider buffering changes in memory before saving a document, if that’s feasible.
Thanks a bunch!
Yes, upon thinking about it I realised which document is causing the issue and it should be straight forward to update the implementation to not create quite so many changes.