I made dnn scheduler and set to run it on every 1 min. It works when I do something on site. But I need to run some actions when I am not on the site. For example insert record to database with currenct time. Is this possible?
In Host Settings, use Scheduler Mode = Timer Method
This will make the scheduler run in a separate thread that is not triggered by page requests.
If the scheduler runs in the timer method, it won't have access to the current HttpContext.
You will also have to make sure that DNN is kept alive, and IIS doesn't shut down the application due to inactivity. Setting the application pool idle timeout appropriately, and pinging the /Keepalive.aspx should take care of this. Nevertheless, using the DNN scheduler for critical tasks is not a good idea.
See Also:
Creating DotNetNuke Scheduled Jobs
DotNetNuke Scheduler
Explained
If you just want database related things, such as inserting a record, you can use database jobs. You didn't mention what dbms you use but almost every database have almost same functionality under different names.
Doing the equivalent of a Cron job is still a pain in the butt on Windows.
The DNN Scheduler will work if you aren't super concerned about when it runs. What you may need to do is have more logic on your end... if it only runs every 10 minutes, or every hour or whatever you may have to look at your database tables, determine last time it ran and then do whatever it needs to do to 'catch up.' In your case add 60 minutes of info versus every minute.
I'm struggling to think of an example of why I would just write to a table every minute or on some interval. If I needed it for a join table or something convenient to report off of you should generate them in larger chunks.
The other option is to write a small .NET windows service which isn't that hard and have it run every minute. That would be more reliable.
Related
Firstly let me apologise, as I don't really know how to phrase the question.
The issue I'm having is trying to keep my database 'alive' while users come to my site. An example being, if I build my c# asp.net application and publish it, then try and navigate to it, it takes a while to respond (which I get, I understand it, this isn't an issue for me) the problem is if some person hasn't been to the site for a while, it seems to take a while again, like a session timer has passed, I'm not sure if this is something to do with App Pool recycling?
I've tried to run a scheduled task to hit the database (trying to keep it responsive) every 15 minutes, but this doesn't seem to work, it works well every 15 minutes for say 5 hours, and then I receive a message on a random call that the request has taken over 4 seconds to respond and therefore fails.
My question then, how do I keep my connection to the database / the site responsive so that each time a person requests it, the site loads quickly, rather than having to 'start up'
Kind regards as always
I suggest to increase connection pool size in your connection string.
This looks like what you want:
Keep an ASP.NET IIS website responsive when time between visits is long: Keep an ASP.NET IIS website responsive when time between visits is long
You might consider IIS application auto-start?
Some web applications need to load large amounts of data, or perform expensive initialization processing, before they are ready to process requests. Developers using ASP.NET today often do this work using the “Application_Start” event handler within the Global.asax file of an application (which fires the first time a request executes). They then either devise custom scripts to send fake requests to the application to periodically “wake it up” and execute this code before a customer hits it, or simply cause the unfortunate first customer that accesses the application to wait while this logic finishes before processing the request (which can lead to a long delay for them).
ASP.NET 4 ships with a new feature called “auto-start” that better addresses this scenario, and is available when ASP.NET 4 runs on IIS 7.5
I am trying to develop an application that will scan a website, get data from the website and save that data into database 3x per day at given hour that can be set in xml configuration file.
As an addition group of users can trigger the start of the application manually max few times per day.
I am looking for pros and cons of using a windows service for this solution or should I set a 3 scheduled tasks that will run the console application?
If I will decide to use a windows service then what is the best way to trigger a manual start of the service while the service is already running? The group of users will have some kind of web interface to trigger manual start.
This could be easily done using a scheduled task. I would just set a 3x scheduled tasks that will run the application at given time and the group of users could just start the .exe file from the web interface. However how to only allow the user to run a manual trigger only if application is not already running?
Since the UI is ultimately in web, and thus the service itself won't need any UI, I would go with Windows service which can be triggered to start by the user through web or automatically as the time comes (by its internal code).
Then, either:
In the service it has something to indicate its status as running which can be captured by the web app to see it, or,
In the web, there is mechanism to request/monitor the service status
Is quite flexible I think. I would go with whichever is easier.
I picked the task scheduler option for my case. It was easier to implement the manual triggering by users mechanism.
Pros - Triggers can be added easly using the taks scheduler library.
I have been given a windows service written by a previous intern at my current internship that monitors an archive and alerts specific people through emails and pop-ups should one of the recorded values go outside a certain range. It currently uses a timer to check the archive every 30 seconds, and I have been asked if I would be able to update it to allow a choice of time depending on what "tag" is being monitored. It uses an XML file to keep track of which tags are being monitored. Would creating multiple timers in the service be the most efficient way of going about this? I'm not really sure what approach to take.
The service is written in C# using .NET 3.5.
Depending on the granularity, you could use a single timer that is a common factor of the timing intervals they want. Say they want to put in the XML file that each archive is to be checked every so many minutes. You set up a timer that goes off once a minute, and you check how long it's been since you did each one and whether to do it or not.
If you're getting a chance to re-architect, I would move away from a service to a set of scheduled tasks. Write it so one task does one archive. Then write a controller program that sets up the scheduled tasks (and can stop them, change them etc.) The API for scheduled tasks on Windows 7 is nice and understandable, and unlike a service you can impose restrictions like "don't do it if the computer is on battery" or "only do it if the machine is idle" along with your preferences for what to do if a chance to run the task was missed. 7 or 8 scheduled tasks, each on their own schedule, using the same API of yours, passing in the archive path and the email address, is a lot neater than one service trying to juggle everything at once. Plus the machine will start up faster when you don't have yet another autostart service on it.
Efficient? Possibly not - especially if you have lots of tags, as each timer takes a tiny but finite amount of resources.
An alternative approach might be to have one timer that fires every second, and when that happens you check a list of outstanding requests.
This has the benefit of being easier to debug if things go wrong as there's only one active thread.
As in most code maintenance situations, however, it depends on your existing code, your ability, and how you feel more comfortable.
I woould suggest to just use one timer scheduled at the least common divisor.
For example configure your timer to signal every second and you can handle every interval (1 second, 2 seconds, ...) by counting the according number of timer ticks.
I want to create a service that will monitor changes to web pages i.e. the page content has been updated. I am trying to think of the best way to achieve this and at present I am considering a couple of options. Note that there could be hundreds of pages to monitor and the interval for checking could be seconds or hours (configurable).
Create a windows service for each page to monitor
Create a windows service that spawns a thread for each page to monitor
Now, I am concerned which of these is the best approach and whether these is an alternative I haven't considered. I thought 1 would have the benefit of isolating each monitoring task but would come at the expense of overhead in terms of physical resources and effort to create/maintain. The second would be slightly more complex but cleaner. Obviously it would also lose isolation in that if the service fails then all monitoring will fail.
I have done something similar and I solved it by having a persisted queue (a SQL Server table) that would store the remote Uri along with the interval and a DateTime for the last time it ran.
I can then get all entries that I want to run by selecting the ones that has lastRun + interval < now.
If your smallest interval are in the region of seconds, you probably want to use a ThreadPool, so that you can issue several request at the same time. (Remember to adjust the maxConnections setting in your app.config accordingly).
I would use one Windows service (have a look at the TopShelf project for that) and I would then have Quartz.Net trigger the jobs. With Quartz, you can control whether it has to wait for previous jobs to finish etc.
Creating one Windows Service is the way to go... regarding the failure of this windows Service there are several measures you could take to deal with that - for example configure windows to automatically restart the Windows Service on failure...
I would recommend using a thread pool approach and/or a System.Threading.Timer in combination with a ConcurrentDictionary or ConcurrentQueue .
I have to create an app that will read in some info from a db, process the data, write changes back to the db, and then send an email with these changes to some users or groups. I will be writing this in c#, and this process must be run once a week at a particular time. This will be running on a Windows 2008 Server.
In the past, I would always go the route of creating a windows service with a timer and setting the time/day for it to be run in the app.config file so that it can be changed and only have to be restarted to catch the update.
Recently, though, I have seen blog posts and such that recommend writing a console application and then using a scheduled task to execute it.
I have read many posts talking to this very issue, but have not seen a definitive answer about which process is better.
What do any of you think?
Thanks for any thoughts.
If it is a one per week application, why waste the resources for it to be running in the background for the rest of the week.
A console application seems much more appropriate.
The typical rule of thumb that I use is something along these lines. First I ask a few questions.
Frequency of Execution
Frequency of changes to #1
Triggering Mechanism
Basically from here if the frequency of execution is daily or less frequent I'll almost always lean towards a scheduled task. Then looking at the frequency for changes, if there is a high demand for schedule changes, I'll also try to lean towards scheduled tasks, to allow no-coding changes for schedule changes. lastly if there is ever a thought of a trigger other than time, then I'll lean towards windows services to help "future proof" an application. Say for example the requirement changes to be run every time a user drops a file in X folder.
The basic rule I follow is: if you need to be running continuously because events of interest can happen at any time, use a service (or daemon in UNIX).
If you just want to periodically do something, use a scheduled task (or cron).
The clincher here is your phrase "must be run once a week at a particular time" - go for a scheduled task.
If you have only one application and you need it to run once a week may be scheduler will be good as there is no need to have separate service and process running on the system which will be idle most of the time.