Thanks a lot Jens!
Then I change that method to:
- (void) observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void*)context
{
if (object == self.pullReplication && [self.pushReplication status] ==
kCBLReplicationStopped) {
NSLog(@"CouchDBProvider Replication Done");
}
if (object == self.pushReplication && [self.pushReplication status] ==
kCBLReplicationStopped ) {
}
}
And I also add the following method to synchronously make sure the
replication is completed:
-(void) completeSyncReplication{
while (([self.pullReplication status] > kCBLReplicationStopped ) && ([
self.pushReplication status] > kCBLReplicationStopped )){
}
}
Thanks a lot!
On Monday, February 10, 2014 5:10:53 PM UTC+1, Jens Alfke wrote:
>
>
> On Feb 10, 2014, at 3:26 AM, [email protected] <javascript:> wrote:
>
> So this is the code I have having as CBLReplictaion pullReplication and
> pushReplication:
> http://pastie.org/private/a35qxzxa8yba8rsuoeznq
>
>
> Looks basically OK, but this test is incorrect:
>
> if (object == self.pullReplication && [self.pullReplication changesCount]
> == 0) {
> NSLog(@"Info : CouchDBProvider Replication Done");
> }
>
> The right way to check if the replication is done is to compare its status
> property to kCBLReplicationStopped (or kCBLReplicationIdle for a continuous
> replication.) The sample apps including Grocery Sync demonstrate this.
>
> The problem with checking changesCount is that it'll also be zero at the
> *start* of replication before the replicator figures out what documents
> it needs to download.
>
> The point is that the replication is done correctly, but I have observed
> that it's done quickly untill I get the following warning:
> 2014-02-10 12:17:39.530 xxxx[9100:501b] -[CBL_FMDatabase
> executeUpdate:error:withArgumentsInArray:orVAList:]:757 Database
> busy (/Users/xxxxx/Library/Application
> Support/xxxxxx/CouchbaseLite/uid_52f206f367842.cblite)
>
>
> This means that a thread is keeping the SQLite database busy for a long
> time, blocking another thread from accessing it. It isn't an error, but it
> indicates a performance problem.
>
> When this happens, the replication is stopped for a time. It can take the
> replication to resume maybe 1 minute or 2. Can I do something in order to
> wait less time.
> For more information, I am moving moreless 35.000 documents with a total
> size of 25MB.
>
>
> My guess is that your main CBL-using thread is querying a view when this
> is going on. The initial query of a view has to run the map function on
> every document in the database. It shouldn't take as long as you're saying
> (a minute), but perhaps either (a) your map function is inefficient, or (b)
> CBL's view updating code is behaving slowly in this case.
>
> The way to tell is to pause the app in the debugger while this is going
> on, and look at what your threads are doing. If your database thread is
> inside a call to -[CBLQuery run:], then this is what's going on. In that
> case could you post a backtrace of that thread? (Select the thread and then
> enter "bt" in the debugger console.)
>
> —Jens
>
>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/526964c1-dc56-4938-8f0a-f48832d0c082%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
