Getting notifications when run on background thread

[Adam Wilson]

I've added an option to a library I'm using to replicate on a background thread.  

The relevant code:

[manager backgroundTellDatabaseNamed:databaseLocal to:^(CBLDatabase *bgdb)
{
 NSLog(@"Starting pull on background thread...");
 // Inside this block we can't use `db`; instead use the instance given (`bgdb`)
 [self startPull:bgdb
 withRemoteUrl:remoteUrl
 withRemoteUser:remoteUser
 withRemotePassword:remotePassword
 withEvents:events
 withOptions:options];

 // Required in order to listen to events
 [[NSRunLoop currentRunLoop] run];
}];

`startPull` contains:

CBLReplication* pull = [db createPullReplication: url];//...
[pulls setObject:pull forKey:db.name];
// Add the events handler.
if (events) {
 [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleReplicationEvent:) name:kCBLReplicationChangeNotification object:pull];
}
[pull start];

(Full code is here)

The notifications work fine when the method is called from outside the backgroundTellDatabaseNamed block. I add the `[[NSRunLoop currentRunLoop] run]` line but that does not seem to have got it working. 

Anything I've missed or need to consider to get notifications when replicating in the backgroundTellDatabaseNamed block?

[Jens Alfke]

On Dec 29, 2017, at 7:40 AM, Adam Wilson <adam.el...@gmail.com> wrote:

I've added an option to a library I'm using to replicate on a background thread.  

This isn’t necessary: replication already runs on a background thread. The CBLReplication class just sends messages to the background replicator and relays notifications from it, so all CBLReplication methods return immediately.

TL;DR: Just use CBLReplication on the main database; it’s asynchronous and won’t block your main thread.

There are a couple problems with the code you showed.

• Using CBLReplication inside the background block probably won’t work, basically because the background database (`bgdb`) is itself the database instance that runs the real replicator work. Trying to predict what would happen is making my head hurt; simpler just to say Don’t do that.
• The call to `[[NSRunLoop currentRunLoop] run]` will block forever, preventing the background database from handling any more requests. Don’t do that either :)

—Jens

[Adam Wilson]

Thanks Jens,

Good to know. The issue I have is that the UI is getting blocked during very large replications (iOS). 30,000 documents each with a small binary attachment. The UI freezes/slows even on the simulator. Is there a way around this? Can the replication run on a lower priority thread? 

[Jens Alfke]

On Jan 2, 2018, at 1:14 PM, Adam Wilson <adam.el...@gmail.com> wrote:

Good to know. The issue I have is that the UI is getting blocked during very large replications (iOS). 30,000 documents each with a small binary attachment. The UI freezes/slows even on the simulator. Is there a way around this? Can the replication run on a lower priority thread? 

The problem is probably that you have database observers registered that are firing for every document received, and the observers are doing something expensive enough to cause trouble. Try using Instruments to profile the app.

—Jens

Jens Alfke — Mobile Architect — Couchbase, Inc.

[adam wilson]

Thanks, that makes sense, I do have observers running, and they are sending messages across the JS/native border in a React Native app, which is notoriously expensive. I'll take a look.

--
You received this message because you are subscribed to a topic in the Google Groups "Couchbase Mobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mobile-couchbase/0MikI5KM9g4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mobile-couchbase+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/E7D9D692-CF38-460F-9C3C-B94404DBF430%40couchbase.com.

For more options, visit https://groups.google.com/d/optout.