One shot sync not pulling data properly in background #1898
Comments
|
The key is the message I can't remember what we've done to support replications that start in the background; @pasin? |
|
We always suggested users to reset the suspened flag but that does't work for a single short replicator. Another thing is that I don't think it's possible to reset the suspened flag from the rest API. I was thinking that we should have an option that allows the replicator to run in the background but the app needs to manage the background task by itself (this is what I'm implementing for 2.0). We could do this for 1.4.1 as well. |
|
But I think we should allow the replicator to start and run in background til idle before suspeneding it. So this is a bug. |
|
@pasin ,do we have any quick workaround for this issue? Is there a way we can detect one shot sync stopped and start full sync? Note : We cannot run full sync always in background, this will result in CPU usage crash. We want to start Full sync conditionally in background. |
|
There is no workarounds. I reviewed the code today, and it seems like there is a race between setting an internal active flag and checking the flag when detecting that the app is in the background. Basically this line is called from the main thread, but the active flag is set on the replicator thread. I'm working on the fix. |
Not sure I understand your question, basically one short replicator will run until caught up unless there is an error occurred. To know the status, you can subscribe for |
* Currently some variables (_active, _filesystemUnavailable, and _deepBackground) could be accessed from different threads (main thread and replicator thread). Fixing this by always executes background/forground handling codes on the replicator thread. * This is also fixed the issue that the replicator (especially pull replicator) is suspended immediately when starting it in the background. Basically there is a race when accessing the _active variable (#1898)
|
@msanilkumar2020 I made the fix in |
|
Sure @pasin , will test our app with this changes. |
* Currently some variables (_active, _filesystemUnavailable, and _deepBackground) could be accessed from different threads (main thread and replicator thread). Fixing this by always executes background/forground handling codes on the replicator thread. * This is also fixed the issue that the replicator (especially pull replicator) is suspended immediately when starting it in the background. Basically there is a race when accessing the _active variable (#1898)
|
The PR has been merged the master branch. I'm closing the ticket now. Please reopen if you still see the issue. |
snej
changed the title
|
After merging this changes we are getting lot of Badf00d crashes, main thread is hanged more than 10 seconds. Exception Type: EXC_CRASH (SIGKILL) |
|
The replicator's resuming is blocked for some reason when the app is on foregrounding. Can you provide the backtrace of all threads? |
|
Uploading crash file, this issue is reproduced frequently after merging this changes. |
|
In the crash log, the background CBL thread is running a view query initiated by a REST call. It's not stuck, just in the middle of file I/O initiated by SQLite. The main thread is waiting on that, and it's apparently taking long enough that the OS decides the app is hung and kills the process. The question is why there are REST calls happening while the app is in the background. The replicator is running, but there's obviously no UI to refresh. I'm assuming this is a PhoneGap app? It should probably ignore database changes while it's in the background. This will keep the CBL thread responsive. |
|
@snej , |
* Reverted the fix back to 1.4.0 that executes background / foregrounding logic on the main thread instead of on the replicator thread which could block the main thread. * Make CBLRestReplicator’s _active an atomic property. * In `-backgroundTaskExpired` set `_deepBackground = YES` on the main thread instead of on the replicator thread as it has been done in 1.4.0.
* Reverted the fix back to 1.4.0 that executes background / foregrounding logic on the main thread instead of on the replicator thread which could block the main thread. * Make CBLRestReplicator’s _active an atomic property. * In `-backgroundTaskExpired` set `_deepBackground = YES` on the main thread instead of on the replicator thread as it was in 1.4.0. #1898
* Reverted the fix back to 1.4.0 that executes background / foregrounding logic on the main thread instead of on the replicator thread which could block the main thread. * Make CBLRestReplicator’s _active an atomic property. * In `-backgroundTaskExpired` set `_deepBackground = YES` on the main thread instead of on the replicator thread as it was in 1.4.0. #1898
* Reverted the fix back to 1.4.0 that executes background / foregrounding logic on the main thread. * In CBLRestReplicator.m, make CBLRestReplicator’s `_active` property atomic. * In CBLRestReplicator.m, moved calling `[self setupBackgrounding]` to the end of the `-start` method. * In `-backgroundTaskExpired` of CBLRestReplicator+Backgrounding.m, set `_deepBackground = YES` on the main thread instead of on the replicator thread as it was in 1.4.0. #1898
|
After merging this change, we are not getting crash but replication is stopping immediately after entering background. We are not able to utilize 180 seconds of background time. We need to pull the documents in background after receiving Push notification. After this changes that is failing. For all restapi call, we are getting response as offline even sync is not starting. [01/31 18:12:52:707][ 0x1c08718c0]Type-Sync , Message-CBLRestPuller[https://919800010101:@sync.xxxxxxxxxx.com/ptxdata]: SUSPENDING [01/31 18:12:52:722][ 0x1c08718c0]Type-Router , Message-Response -- status=200, body=399 bytes |
|
I will test this. |
|
@pasin , |
|
Sorry, I don't have update on this. I still don't have a chance to look at the issue. |
|
@msanilkumar2020 I have tested the fix and I have not observed the same issue anymore. Could you please share the log after picking up the fix? Also please use single shot replicator as there is no REST API to reset the suspend flag of the continuous replicator. |
|
Assuming works since we haven't heard anything. |
Hi,
We have have requirement where we need to download meta-document in background when we receive remote notification. Remote notification will give 30 seconds of execution time.
For this purpose we are using one shot sync, we are using Rest-based Api to start one shot sync.
Issue- Some time background one shot sync will work and some time it wont work.
Received Remote notification and stated one shot sync
I am not able to get why puller stopped without pulling the changes received from change tracker. Do we have any restriction in background fetching data
The text was updated successfully, but these errors were encountered: