I've got a problem. I've got one scheduled task that stops running.
The task is set to run every minute. It hits an url in the same site. All log entries says "task60 has been called with response: true". The log shows well over 100 succesfull log entries until 11 today, then one logentry around 18 and then one more around 22.
The site is an Umbracy 4.7 with sql ce running net 4 in integrated mode in its own app pool. iis 7.5
No entries in event log.
Visiting the site does not make the scheduled tasks start again. Also the site has visitors - 20 / 30 visit during the day.
After the website spins up, umbraco will wait 10 minutes before running the scheduled tasks for the first time (as far as I recall). It could be an issue with the site not having 'enough' visits to keep the app pool alive?
Has it just stopped all by itself, or has anything changed? Maybe setting up a pingdom account (or a scheduled windows task) to ping the site continuously will help determine if that is the issue?
I cant believe it's an issue of "not enough visitors if the scheduler is scheduled to hit same site every minute and having 20 - 30 visitors every during the day. Also I'm confused about that me loggin in to umbraco doesnt matter either. I've waited well over 10 minutes for it to kick in (since around 18)
I just touched the web.config and that helped. Now the log displays a task run every minute again.
I'm gonna start a pingdom account for this. it's a great idea but ... something must be wrong.
I don't know if it could be something that would crash the timer thread somehow? Has it been running steady before, and just started getting unstable now?
I spent a few hours today to see if I could finally get to the bottom of this, and I think I have found the issue.
It seems that the time is saved to a non static property on the requestModule, so when the module gets disposed, and the garbagecollector comes by, then the timer thread will disappear. The problem now is, that the property that indicates wether the timer has been created _is_ static, so the next time a request comes in, it will look as if the thread is running, and it will not be created again.
The solution would be to make the timer property static, so that it does not get garbagecollected with the module.
I will se if I can figure out how to get this in the core somehow :-) In the meantime, let me know if you want to create a fix from the source code?
Wow - thanks for working that out. Fantastic work! Its been a problem in a few installations for me. You dont have to create a fix for me as the pingdom solution works fine for now.
scheduled tasks stops
Hi all,
I've got a problem. I've got one scheduled task that stops running.
The task is set to run every minute. It hits an url in the same site. All log entries says "task60 has been called with response: true". The log shows well over 100 succesfull log entries until 11 today, then one logentry around 18 and then one more around 22.
The site is an Umbracy 4.7 with sql ce running net 4 in integrated mode in its own app pool. iis 7.5
No entries in event log.
Visiting the site does not make the scheduled tasks start again. Also the site has visitors - 20 / 30 visit during the day.
Any clues?
Best
Jesper
After the website spins up, umbraco will wait 10 minutes before running the scheduled tasks for the first time (as far as I recall). It could be an issue with the site not having 'enough' visits to keep the app pool alive?
Has it just stopped all by itself, or has anything changed? Maybe setting up a pingdom account (or a scheduled windows task) to ping the site continuously will help determine if that is the issue?
Hi Morten,
I cant believe it's an issue of "not enough visitors if the scheduler is scheduled to hit same site every minute and having 20 - 30 visitors every during the day. Also I'm confused about that me loggin in to umbraco doesnt matter either. I've waited well over 10 minutes for it to kick in (since around 18)
I just touched the web.config and that helped. Now the log displays a task run every minute again.
I'm gonna start a pingdom account for this. it's a great idea but ... something must be wrong.
/Jesper
I read that as 20-30 visitors a day.
I don't know if it could be something that would crash the timer thread somehow? Has it been running steady before, and just started getting unstable now?
I spent a few hours today to see if I could finally get to the bottom of this, and I think I have found the issue.
It seems that the time is saved to a non static property on the requestModule, so when the module gets disposed, and the garbagecollector comes by, then the timer thread will disappear. The problem now is, that the property that indicates wether the timer has been created _is_ static, so the next time a request comes in, it will look as if the thread is running, and it will not be created again.
The solution would be to make the timer property static, so that it does not get garbagecollected with the module.
I will se if I can figure out how to get this in the core somehow :-) In the meantime, let me know if you want to create a fix from the source code?
Hi Morten,
Wow - thanks for working that out. Fantastic work!
Its been a problem in a few installations for me. You dont have to create a fix for me as the pingdom solution works fine for now.
Best,
Jesper
Comment author was deleted
Awesome Morten, if you can point me to what needs to be changed I can get this in the core for the 4.7.1 release
Hi Tim
The way I see it, the timers need to be static. So they should be changed from
namespace umbraco.presentation { /// <summary> /// Summary description for requestModule. /// </summary> public class requestModule : IHttpModule { protected Timer publishingTimer; protected Timer pingTimer;to
namespace umbraco.presentation { /// <summary> /// Summary description for requestModule. /// </summary> public class requestModule : IHttpModule { protected static Timer publishingTimer; protected static Timer pingTimer;This will keep them from being garbagecollected when the first instance of the request module is disposed.
Comment author was deleted
Thanks Morten, will get this in the 4.7.1 release
Did this ever get fixed? We're still on 4.7.0 and need to know if this is another reason for us to upgrade.
I've just checked the source for 4.11.4 & 6.0 and yes this has been updated.
is working on a reply...