-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CBL local replication change notifications #15
Comments
Does this only happen with replications between two CBL databases?
This is on B, right? |
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. |
Jens 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. |
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. |
Jens 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. Andy |
It looks like internal replications (possibly all replications) are not correctly firing change notifications on the target datbase when it is local.
Test scenario
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.
The text was updated successfully, but these errors were encountered: