CBL local replication change notifications #15

march44 opened this Issue Feb 25, 2013 · 5 comments


None yet

2 participants

march44 commented Feb 25, 2013

It looks like internal replications (possibly all replications) are not correctly firing change notifications on the target datbase when it is local.

Test scenario


Local CBL DB (A)
Local CBL DB (B)

Remote Sync_gateway (C)

I have a local persistent/continuous PUSH replication setup between A ---> B

I have validated that this is working correctly.

I have a persistent/continuous PUSH replication setup between B ---> C

I have validated that writing a document directly to B is correctly replicated to C

However documents replicated from A ---> B are not automatically replicated to C, if I directly write a document to B after replication from A ---> B has completed, the directly written document (in B) is replicated to C but NOT the documents that were previously replicated from A ---> B.

If I background/foreground or restart the App then the replicated documents in (B) are picked up and replicated to (C) successfully.

I enabled -LogCBLDatabase YES and see the following in the console

21:46:05.326| CBLDatabase: Begin transaction (level 1)...
21:46:05.359| CBLDatabase: Commit transaction (level 1)
21:46:05.375| CBLDatabase: Posting 1 change notifications
2013-02-24 21:46:05.378 meyumeapp[21409:150f] 21409: CFNetwork internal error (0xc01a:/SourceCache/CFNetwork/CFNetwork-609/Connection/URLConnectionClient.cpp:2341)
21:46:05.398| Sync: ReplicatorManager: Updating {5471EC1A-35A1-44E6-81B4-39FDE851F694 #7-241139593a5fe641d3c244813552c280} with {
"_replication_id" = "EB288E11-28EE-43FB-A92A-4086AB108408";

So it looks like the replicator is calling the CBLDatabase+Internal postChangeNotifications selector, but the notifications are not being received.

In the above you will see a CFNetwork error, but I do not know where this is coming from, only that it appears each time there is a notification from the replicator.

I am also seeing an issue with the live queries, where it does not update for docs inserted by the replicator, this also appears to be a problem with the receipt of notifications on the associated database.

All databases, views, queries e.t.c are being created in the AppDelegate or in view controllers, so they should all be running on the main thread and runloop.

snej commented Feb 26, 2013

Does this only happen with replications between two CBL databases?
Are A and B in the same process or in different processes/devices?

I enabled -LogCBLDatabase YES and see the following in the console

This is on B, right?

snej commented Feb 26, 2013

Wait, I know why this is happening. The HTTP listener runs on a background thread and has its own object instances for the database, etc. And I just found a bug where change notifications posted by a database on one thread weren't being picked up and rebroadcast by a database (on the same file) on another thread — this is supposed to happen but at some point the code to support it broke and I didn't notice.

march44 commented Feb 26, 2013


Hi, although I have the HTTP listener running I am not using it in this test, A and B are local CBLDatabase instances and I pass their URL's to the replicators using database.internalURL.

I can see URL's of the form: http://server1.cblite./mydb in the console log

The replications are all setup in the AppDelegate, but I don't know if this forces them all to run on the same thread.

snej commented Feb 26, 2013

Sorry, it's actually the router (the thing that handles the REST API) that runs on a background thread. So the threading issue applies even in your case, without the listener.

I have a fix and I'm testing it out right now. Should be able to push it this afternoon.

march44 commented Feb 26, 2013


Hi, missed a question.

Yes I think that it is only for internal replications, although these are all limited to push Replications right now due to the pull defect #5 . For the full test I have

A(CBL) ---> B (CBL) ---> C (sync_gateway) ---> D (CBL) ---> E (CBL)

If I manually place files in B they are replicated through to D and then replicated to E, but a live query on E does not update, suggesting the same issue as replicating from A ---> B.

I hope that makes sense.


@snej snej added a commit that closed this issue Feb 26, 2013
@snej snej Propagate change notifications between multiple DB objects on the sam…
…e physical database

In multi-threaded environment, there will be multiple CBLDatabase instances on the same database.
They need to notify each other when they make changes. For example, a background instance run by
the router will make changes due to REST API requests, which need to be relayed to the foreground
db so the UI can be updated.
This used to be implemented but broke during refactoring. Once I fixed that, I found it had problems
anyway, so I fixed those.
Fixes #15.
@snej snej closed this in e48a53d Feb 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment