App not responding #740
Comments
|
I have reproduced this as well. I was testing the individual download of content items and the app froze.
I restarted the app - and it froze right away again.
|
|
I can reproduce this on ASUS CM3000DVA Chromebook (arm). I check the log while I follow the reproduce steps. Looks like the Endless Key's kolibri server process is killed when the user browses the external link with a browser!?!? Then, when I go back to Endless Key app, it cannot find the kolibri server process. Because, it is killed. |
|
Very likely related to the thumbnail download going on in the background - so moving this to the in progress column. |
|
Actually, this appears to be more that the server is being stopped by the activity lifecycle hooks, but they don't block. Then it gets resumed before the server hasn't finished stopping and the whole thing blows up. This goes back to https://phabricator.endlessm.com/T34138. What makes this particularly bad is that Kolibri tries to cancel running tasks but it's really slow about it. I honestly don't know what to do here. I actually ran into this same thing when playing with chaquopy. From what I could tell, only In my chaquopy experiment I put the server in a bound service and it worked great. The activity could cycle quickly through states or be killed completely and the server would be unaffected until the activity was unbound either actively or by being killed. So, it would be great to have the server as a bound service, which is the opposite of what I suggested almost exactly a year to the day. Unfortunately, python-for-android makes it very hard to do any of that. The other part that would be good would be to put the task workers in another service, possibly using All that to say that this is going to be hard to fix this correctly with python-for-android. With chaquopy where you actually control the whole app it would be much easier. |
|
I think in the very short term what to investigate is why it takes kolibri so long to cancel the download tasks. I think if the server can be stopped quickly this will be much less of an issue. However, the issue with the app freezing outside of a lifecycle change is likely different. |
|
Due to Android activity's life cycle issue, moving kolibri server as a bound service is a correct solution. |
|
Apparently, you can't cancel running tasks in Kolibri, so the server (really the Alrighty then. What we ultimately want is to not have the tasks running from the server bus. Ideally that would be a separate Android bound service that could run and stop independently of the server. As mentioned above, getting that going in p4a would be rough. I did it for the WorkManager stuff, but then Richard had to make a bunch more nontrivial changes to get it to work right. Maybe what we can do is start 2 process buses from the python code. One runs just the server and the other runs just the workers. It's all still in the same process with the main activity, but then we can stop just the server bus in the |
|
Some tasks can be cancelled, and generally for long running tasks it is preferable that they be marked as such. Tasks that implement cancellation should (and in the case of Kolibri's built in content import tasks, do) check for cancellation during their run time code to ensure interruptability. There is currently a bug (as linked by @dbnicholson) because these tasks are incorrectly canceled only via their futures objects during worker shutdown, and not leveraging the more extended Kolibri mechanism for this. On the whole though - it is precisely this sort of behaviour that prompted us to do the refactor to use WorkManager as the task executor - it completely avoids having to cancel and restart tasks based on app teardown, because you delegate execution of the task to Android. Previously, the only alternative was to force a persistent foreground notification, which meant that the server and task runner never stopped - this could be ameliorated by adding an |
+1000. I didn't get why you wanted WorkManager at the time, but I see it now. Even without WorkManager, having the workers run persistently in a separate bound service would be much more robust. I'm trying to avoid rearchitecting the app like you did at the moment because we're about to change focus away from Android for a bit. What I really want to do is stop applying duct tape to python-for-android and just port the whole thing to chaquopy. This would all be achievable there in a sane way. |
Running Kolibri tasks cannot be cancelled[1] and shutting down the process bus running them will block until the running tasks complete. This means the Kolibri server can't be stopped quickly or reliably during the activity's `onActivityStopped` hook. To workaround that, move the task workers spawned from the `ServicesPlugin` into a separate process bus. This bus will only be stopped when the activity is destroyed (or killed). Besides making the server lifecycle much more reliable, it allows tasks to continue running and starting in the background as long as the activity process is alive. Ideally the server and workers would be separate services outside of the main webview activity, but python-for-android makes that really hard to accomplish. 1. learningequality/kolibri#10249 Helps: endlessm/kolibri-explore-plugin#740
Running Kolibri tasks cannot be cancelled[1] and shutting down the process bus running them will block until the running tasks complete. This means the Kolibri server can't be stopped quickly or reliably during the activity's `onActivityStopped` hook. To workaround that, move the task workers spawned from the `ServicesPlugin` into a separate process bus. This bus will only be stopped when the activity is destroyed (or killed). Besides making the server lifecycle much more reliable, it allows tasks to continue running and starting in the background as long as the activity process is alive. Ideally the server and workers would be separate services outside of the main webview activity, but python-for-android makes that really hard to accomplish. 1. learningequality/kolibri#10249 Helps: endlessm/kolibri-explore-plugin#740
Running Kolibri tasks cannot be cancelled[1] and shutting down the process bus running them will block until the running tasks complete. This means the Kolibri server can't be stopped quickly or reliably during the activity's `onActivityStopped` hook. To workaround that, move the task workers spawned from the `ServicesPlugin` into a separate process bus. This bus will only be stopped when the activity is destroyed (or killed). Besides making the server lifecycle much more reliable, it allows tasks to continue running and starting in the background as long as the activity process is alive. Ideally the server and workers would be separate services outside of the main webview activity, but python-for-android makes that really hard to accomplish. 1. learningequality/kolibri#10249 Helps: endlessm/kolibri-explore-plugin#740
Running Kolibri tasks cannot be cancelled[1] and shutting down the process bus running them will block until the running tasks complete. This means the Kolibri server can't be stopped quickly or reliably during the activity's `onActivityStopped` hook. To workaround that, move the task workers spawned from the `ServicesPlugin` into a separate process bus. This bus will only be stopped when the activity is destroyed (or killed). Besides making the server lifecycle much more reliable, it allows tasks to continue running and starting in the background as long as the activity process is alive. Ideally the server and workers would be separate services outside of the main webview activity, but python-for-android makes that really hard to accomplish. 1. learningequality/kolibri#10249 Helps: endlessm/kolibri-explore-plugin#740
|
I usually test with the Android emulator and I found there are a couple knobs to reduce the hardware resources with QEMU: That should help trigger ANRs more easily. |
|
I am reducing the priority here since it can not be reproduced as often anymore. |
|
Moving out of current sprint. This should be re-tested when we switch to Chaquopy. #185 |
|
With the conversion to chaquopy landed now in endlessm/kolibri-installer-android#185, I think this is testable again. I don't think there should be any ANRs since Kolibri runs in a separate service. The activity is just the webview and all interactions with the Kolibri service are asynchronous. @vanessa-chang could you QA this again with 420 Narwhal 7.8 from internal testing? |
|
I have not able to reproduce this issue today with 420 Narwhal 7.8. I will close this issue first. |
App is easily freezed when testing the app version app version: 6.31-379.
It's noted that the app is easily freezed in some scanarios:
eg. After access the external link opened in the default browser.
When downloading an individual content that takes a long time (#739)
Test the latest 6.32-380
Reproduce steps:
Result:
The app is not responding.
This issue cannot be reproduced in the Windows app.
Log:
app freezes.txt
The text was updated successfully, but these errors were encountered: