I'm developing a WP8.1 SL app which uses background tasks (not agents!).
My task is triggered by a TimerTrigger - once every 30 minutes (which I believe is the minimum interval for Windows Phone, right?). It is doing a lot of work, and for some reason, sometimes it gets interrupted - that is, it stops in the middle of it. The way I know it's in the middle of it is because I log what's happening and the task's work is basically the same every time.
I deployed the app to my device yesterday to test a new approach, and everything was working fine - the background task was doing everything every time it was started - worked like a charm. Today my device needed a soft reset, so I did it (nothing was working, it happens from time to time since I updated to WP8.1). Since that moment, the background task gets interrupted every time, right in the middle of it, just as with the previous approach.
Any ideas what can cause this? I'm thinking it may be connected to the soft reset, because - 100% success rate before it, 0% after that.
What I've tried so far:
I'm logging errors, I have a try-catch around everything, I've subscribed to the UnobservedException event and to the task's Canceled event, and I'm logging the suspension count - none of these things help. There seem to be no errors, it's not suspended, and it's not canceled.
I'm logging the current memory usage from time to time, and it's about 16-17MB. On my device, the limit should be 30MB, so I don't think that's a problem.
I'm calling RequestAccessAsync wherever I can. I thought once should be enough, but since that soft-reset issue, i decided to put it in 1-2 other places to check if it's causing the issue. Well, it's not, or at least this didn't fix it.
What I'm not sure about:
I have no idea how to check the CPU time my task has consumed. I can't find a good/reliable way to do so. Also, I can't find any info that would explain why the task would be stopped in the middle sometimes, and other times - it would work fine.
Any ideas why my background task is sometimes stopped at the middle? I'm really having a hard time determining how to fix/improve the app and will it work at all.
Thanks.
So, I think I found what my problem was.
First of all, the background task just needed a lot of CPU time, more than the limit, and that's why it was getting killed in the middle.
The reason why it was working sometimes, was because sometimes the device on which I was testing treated the app as being in debug (or with attached debugger). In this case the restriction on CPU time is removed.
So, even if I uninstall the app and rebuild it in Release and redeploy, and start it without the debugger attached, the device was NOT enforcing the constraints. That only happens, if I have started the app with the debugger at least once (or maybe the first time) after it's deployed. Restarting the device (just power off and then turn on) fixes this.
While I was testing, using the same build of an app, its background task ran for 40 MINUTES on one device, and just 3-4 seconds on another. After I restarted the first device, the background task started behaving normally (running for just a few seconds).
So, if you want to test your background task for the CPU constraint:
You must be testing on a device, not on the Emulator.
Uninstall the app, if it's installed.
Restart the device.
Deploy a Release build of the app.
Run the app, so that it can register the background task, and then close it.
Wait for the background task to be invoked. (You could add a trigger that can be forced, like TimeZoneChanged or UserPresent, so that you could quickly test it.)
P.S. This may not be the perfect answer, but these are my observations, and they helped me solve my problem. This by far is the best method I have found for testing the CPU time, and it's far from perfect. So, if anyone has better ideas, please share them.
Related
I am running a site with django+apache+ssl+mysql+cloudfron+s3.
However, I discovered that the ttfb time increases significantly when the first connection and caching setup time ends at some point.
(response starts after pause for about 5 seconds)
After uninstalling Apache, I tried debugging in debug mode and in Gunicorn.
There were no issues with ttfb in debug mode. However, I found out that I had the same problem when using Gunicorn.
So I looked all over apache, db, ssl, django template rendering, etc.
I don't know what's causing the bottleneck.
Which part should I look at more?
Oh, and I also found that if I send a request twice in a row, I get a response right away without any pause.
Please advise. I think my head is going to break...
edit : I tested it without any cdn or database page, but the result was the same.
I got a Colab Pro+ because I wanted to use the background execution option.
I enabled the background execution and GPU type and started my code.
My code is a simple CNN on Tiny ImageNet, which requires several hours of training on a GPU.
I closed the browser, and after one-two hours, I returned, and everything was frozen!
How can I resolve this issue?
This happens to me as well and the best solution I've been able to come up with (which works inconsistently, but seems to help a lot more that otherwise) is to prevent my screen from locking. Let me explain.
I run Colab Pro+ on a Macbook laptop, and the battery-saving settings are ordinarily such that the screen locks when the laptop is idle for 5 mins, the lockscreen comes up. I noticed that for some reason Colab was much more likely to freeze and disconnect if I was away from the laptop than if I were working on it for hours as it ran, so to superficially mimic this, I changed my settings to never lock the screen. And I then I realized that with these settings Colab would freeze and disconnect much less frequently, and I could successfully let it run overnight and check it in the morning. [Edit: let me clarify that I have not tried this while closing the browser. So I can attest to the efficacy of my method if you leave the browser open].
I have to say though, that it's been bad for my laptop and it's unacceptable that this is necessary despite what we pay for Colab Pro+. Their product simply does not work as advertised and we have no recourse. If anyone has discovered a better solution (that works) I'm all ears.
An alternative that works for me is to make the navigator click with some interval. You can add the following script to the console. It works well with Colab Pro and Pro+ but remember that, if you use the free account, Colab will disconnect you after some hours.
To open the console press F12 or ctrl/command+shift+i.
function Clicking(){
console.log("Clicking");
document.querySelector("colab-connect-button").click()
}
setInterval(Clicking,50000)
I'm trying to find the source of some "idle" time within a certain page I'm accessing on our system. The problem is weird though to me, as I cant tell the reason for the delay. I'm running this in a single instance of chrome, no other tabs or anything.
The initial load time looks like this:
So it takes a while. But if I refresh this page within 7-8 seconds it will come back really quickly.
I initially though it was a system process on our end and ran Yii's profiler which came back with:
So, it seemed to be a non "system" issue, so went to Chrome's dev tools and the profile comes back with this:
I've read the other question What causes Chrome Timeline Frame to have so much empty white space also.
I'm trying to understanding if it's possible to identify the problem at all and why the page is rendered quickly if the page is refreshed after a few seconds of loading and why it takes so long if the refesh is called after 7-8 seconds of the initial load?
nb Some of the times might not match up as I've run the various profilers a few times. So they might apply to different page refreshes. But you can see the general trend :)
I'm using the AS3 Timer class to sync data between a Flex Mobile app and a server ideally every 30 mins then send a local (distriqt) Notification to the user when action is required.
However, when the device goes into sleep / hibernate mode it seems to slow down, even stop the Timer. I've tried using a lower interval (5mins) but it still only works intermittently.
This is very hard to test as the behavior is different in debug / run modes.
Any suggestions?
Thanks.
Sounds like you might need to change your approach here. Background operation of applications is very different from the foreground.
Your application will run for a little while (depending on the current device memory load among other things) and will then enter a suspended mode, mainly to preserve the application's memory state.
There are some background mode exceptions to this, such as audio playback and location updates, however if you aren't performing these then Apple will most likely reject your application as part of the review process.
You can also investigate the executeInBackground flag on the NativeApplication. This allows a long running task to execute in the background, however this does not guarantee that the application would run in the background continuously.
You can read more here: http://blogs.adobe.com/airodynamics/2012/05/04/air-ios-background-behavior/
UIBackgroundModes: https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW22
We have an air application (native for windows) that after being unused or background for about some hours after you try to use it it got stuck and "not responding" windows message.
No log or error or crash just got stuck.
The best behaviour that we have got is that after some seconds it unstucks but then stucks and unstucks every 30 seconds aprox, so it is anusable.
We have tried some "ugly" tricks like after being out of focus/background for some minutes, goes into front, it goes, but this haven't resolved the above problems.
I understand clearly, that SO (Windows) has removed the cached memory pages associated to this process, however, this is normal for each program, so, it is normal that program (specially visually heavy like ours) come back to use, it takes some seconds to go into memory again.
However after that time of re caching into memory any programs (most) works like a charm.
This is not the case of air app.
is there any trick or recommendation for fixing this?
Maybe we should combine the "to front" trick with some other "dumb processing" to keep the program in memory?
thanks in advance.