I have an asp.net mvc 2 app, and I need to run a task (call WS, save into db) once a day. What is the suggested way for this? One thing, I have a feeling I would like to execute this task from within the webapp.
Does anyone have any suggestions:
I was considering .net quartz or regular System.Timers.Timer?
Does anyone see any problems?
Any other better solutions?
Thanks a lot
--MB
Why do you want to run this from the webapp? You have no way of even knowing if the webapp will be running at the required time. I would recommend you look at Windows Services
web apps are not the best host for a scheduled task. Unless you implement a system to keep the process awake, there's no chance to be sure your schedule will be executed.
Quartz.net is good for that.
It consists in a core module which you can use in your web app to save tasks and a server (windows service) module which executes your scheduled jobs.
I've recently implemented my own windows services and used Sql Server as storage for my scheduled jobs. Everything works pretty well, even if, I had to struggle a little bit to put things together.
The documentations is not always so clear.
Have a look at Quartz.Net, which is available as a NuGet package or from their site.
There are lots of examples of how to set these up, they are very flexible, you just have to define a class which implements IJob with a single Execute() method which gets fired by your choice of triggers.
You could also consider using Windows Workflow Foundation.
Related
I am looking for an options to execute recurring background tasks. The background Task would call the external REST GET request and update the status accordingly in the application database.
Which one of the following would be appropriate, considering that we do not like to maintain separate web.config between the application and the scheduler/task app. Looking for Simple option in .NET/Asp.NET web API context - not looking for any separate installation / 3rd party.
Scheduled task - believe we need to create those many scheduled tasks in a server which points to those many databases? maintainability is a concern?
windows service
Asp.Net background task options
any other better option?
Please provide your insights for this question.
I highly recommend looking at Hangfire to implement background tasks
This works better than a windows service in a cloud environment and supports fire-and-forget and repeat tasks/processing etc and integration is really seamless.
I just noticed your non-3rd party comment, not sure if you mean commercial component, but this is free, via nuget, if that helps?
see: https://www.hangfire.io
Is there any problems with creating a powershell runspace in an asp.net application and running commands?
I have a basic example working fine but I'm wondering if there are any pitfalls waiting for me.
I'm particularly wondering:
Is this an a light-weight inprocess operation or is it firing up another processes that could lead to unpredictable behaviour.
As long as you're not shelling out to powershell.exe explicitly, instead using Runspace and Pipeline objects directly, you can be assured it's fairly lightweight. Btw, if you are trying to interact with cmdlets through C#, only cmdlets that derive from PSCmdlet need a pipeline; ones that derive from Cmdlet directly can be called without a pipeline via the Invoke method. This is the most lightweight approach.
This should be OK. I've not done this in ASP.NET but I have hosted in-process with a desktop app. There is no external PowerShell process spun up unless you use background jobs. I think the Quest folks are also doing something like this with their Mobile Shell.
As I can see, others recommend using PowerShell. Well, personally, I would pay more attention. Why?
Each web request should be processed as quickly as possible and without any blocking. If the script contains commands that work with network, then there could be some timeouts (e.g. if the computer is not accessible). The processing thread will be blocked for all the time and can't serve any other web request. Then soon you might get Internal Server Error and similar responses.
Besides that (not proved) I suspect that PowerShell consumes more memory than similar code in C#.
I don't claim don't use Powershell, just pay attention ;)
I am writing a web application in ASP.NET 3.5 that takes care of some basic data entry scenarios. There is also a component to the application that needs to continuously poll some data and perform actions based on business logic.
What is the best way to implement the "polling" component? It needs to run and check the data every couple of minutes or so.
I have seen a couple of different options in the past:
The web application starts a background thread that will always run while the web application does. (The implementation I saw started the thread in the Application_Start event.)
Create a windows service that is always running
What are the benefits to either of these options? Are there additional options?
I am leaning toward a windows service because it is separated and can run on a different server (more scalable) as well as there is more control over when it is started/stopped, etc. However, I feel like the compactness of having the "background" logic running in the process of the web application might make the entire solution more understandable.
I'd go for the separate Windows service primarily for the reasons you give:
You can run it on a different server if necessary.
You can start and stop it independently of the web site.
I'd also add that it could well have some impact on the performance of the web site itself - something you want to avoid.
The buzz-word here is "separation of concerns". The web site is concerned with presenting the data to the user, the service with checking the integrity of the data.
You can also update the web site and service independently of each other should you need to.
I was going to suggest that you look at a scheduled task and let Windows control when the process runs, but I re-read your question and noted that you wanted the checks to run every couple of minutes. The overhead of starting the process might be too great in this case - though some experimentation would probably prove this one way or the other.
If you use a scheduled task there's also the possibility that you could start the next check before the current one has finished - something you can code for if you're in complete control.
Why not just use a console app that has no ui? Can do all that the windows service can and is much easier to debug and maintain. I would not do a windows service unless you absolutely have to.
You might find that the SQL Server job scheduler sufficient for what you want.
Console application does not do well in this case. I wrote a TAPI application which has to stay in the background and intercept incoming calls. But it did it only once because the tapi manager got GCed and was never available for the second incoming call.
I have a website that's running on a Windows server and I'd like to add some scheduled background tasks that perform various duties. For example, the client would like users to receive emails that summarize recent activity on the site.
If sending out emails was the only task that needed to be performed, I would probably just set up a scheduled task that ran a script to send out those emails. However, for this particular site, the client would like a variety of different scheduled tasks to take place, some of them always running and some of them only running if certain conditions are met. Right now, they've given me an initial set of things they'd like to see implemented, but I know that in the future there will be more.
What I am wondering is if there's a simple solution for Windows that would allow me to define the tasks that needed to be run and then have one scheduled task that ran daily and executed each of the scheduled tasks that had been defined. Is a batch file the easiest way to do this, or is there some other solution that I could use?
To keep life simple, I would avoid building one big monolithic exe and break the work to do into individual tasks and have a Windows scheduled task for each one. That way you can maintain the codebase more easily and change functionality at a more granular level.
You could, later down the line, build a windows service that dynamically loads plugins for each different task based on a schedule. This may be more re-usable for future projects.
But to be honest if you're on a deadline I'd apply the KISS principle and go with a scheduled task per task.
I would go with a Windows Service right out of the gates. This is going to be the most extensible method for your requirements, creating the service isn't going to add much to your development time, and it will probably save you time not too far down the road.
We use Windows Scheduler Service which launches small console application that just passes parameters to the Web Service.
For example, if user have scheduled reports #388 and #88, scheduled task is created with command line looking like this:
c:\launcher\app.exe report:388 report:88
When scheduler fires, this app just executes web method on web service, for example, InternalService.SendReport(int id).
Usually you already have all required business logic available in your Web application. This approach allows to use it with minimal efforts, so there is no need to create any complex .exe or windows service with pluggable modules, etc.
The problem with doing the operations from the scheduled EXE, rather than from inside a web page, is that the operations may benefit from, or even outright require, resources that the web page would have -- IIS cache and an ORM cache are two things that come to mind. In the case of ORM, making database changes outside the web app context may even be fatal. My preference is to schedule curl.exe to request the web page from localhost.
Use the Windows Scheduled Tasks or create a Windows Service that does the scheduling itself.
Jeff has previously blogged about using the cache to perform "out of band" processing on his websites, however I was wondering what other techniques people are using to process these sorts of tasks?
Years ago, I saw Rob Howard describe a way to use an HttpModule to process tasks in the background. It doesn't seem as slick as using the Cache, but it might be better for certain circumstances.
This blog post has the details, and there are many others that capture the same information if you look around.
Windows Service
You may want to look at how DotNetNuke does it. I know it is written in VB.NET, but I retrofitted the code into C#. I was perusing the source and noticed they had a feature in their admin area to setup scheduled tasks. These tasks get setup thru the admin interface and stored in the database. When the site starts, thru the Global.asax file, they either created another thread to run this service that then runs the scheduled tasks at their scheduled time. I can't remember the exact logic, it's been a while, but it is definitely a good resource on how other people have done out of band processes for Asp.Net applications. This technique still keeps the logic within the Asp.Net application, but it runs out of band in my opinion.
if it's primarily data processing tasks and you're using MSSQL, how about scheduled SSIS tasks?
Scheduled tasks using http://www.codeproject.com/KB/cs/tsnewlib.aspx or schtasks.exe.
Quartz.NET
MSMQ
SQL Server jobs
Windows service
System.Threading.Timer or System.Timers.Timer
System.ComponentModel.BackgroundWorker
Asynchronous calls and callbacks
Scheduled tasks, or cron jobs.
The problem with scheduled tasks or cron jobs is that they don't share memory space with the web server. You could set up a scheduled task that requested pages from the web server, but that might create problems with long running tasks. It would be nice to have some low priority threads running on the actual ASP.Net application stack to do simple utility tasks like cleaning up caches, monitoring resources, and just to deal with general housekeeping.
Simple queue files along with a separate agent. For each type of out of band process write a separate agent .exe which watches a directory for queue files that include whatever data is needed to perform the specified process.
This may seem dirty but in the real world I find it gives a lot of flexibility, you aren't doing a lot of processing in ASP.net process space and you could easily adapt this style to farm processing out to cheap Linux servers running the agent process on Mono for when you start needing more RAM/CPU/disk.
If you are most comfortable with asp.net pages you can write a small app to handle your job and then "ping" the app with an outside service that monitors your web site. This will keep the app alive.