Skip to content
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

Closed
ghost opened this issue Feb 25, 2013 · 5 comments
Closed

CBL local replication change notifications #15

ghost opened this issue Feb 25, 2013 · 5 comments

Comments

@ghost
Copy link

ghost 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

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
Copy link
Contributor

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
Copy link
Contributor

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.

@ghost
Copy link
Author

ghost commented Feb 26, 2013

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.

@snej
Copy link
Contributor

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.

@ghost
Copy link
Author

ghost commented Feb 26, 2013

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

@snej snej closed this as completed in e48a53d Feb 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant