I' am building some RSS web service in ASP.net (using IIS as the web server). In it I wand to create some king of RSS reader.
I 'am creating some process that will retrieve the content from the RSS feed every 3 hours.
I want to create a control panel that will give me the ability to start/stop the process, and will have some simple dashboard that will sum the current activity.
I 'am looking for the best way to do that.
I thought about creating a Windows Service on the server, but there are security issues in starting and stopping the service from a web interface.
What is the right way to do it?
you could create your service like this
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
the current state (start/stop) could be set with a static variable (which is the same for the whole AppDomain) or from a config file (which would be better because it survives a AppDomain restart)
A windows service is the right way to perform scheduled tasks on a web server, no question, but I'd argue that a web-based control panel isn't really necessary. Can't you just RDP to the server when you want to start / stop / restart the service?
Related
I want my application to be in 2 phases. 1 part will simply fetch data in json format from an API and store it to a SQL database(or maybe a NO-SQL) and the other half(the web part) will read the data and implement customize alerts. So, basically i need to create a worker for the fetch process. But I'm confused between worker role and web role in Azure. Kindly help me what's the best possible way to implement this design?
You can just merge both in the same web role - the part of code running in IIS (the ASP.NET project created when you create a web role from a Visual Studio template) will handle web requests and the part running the "role entry point" will run the fetch process. Unless you absolutely need to scale them separately this will give you a simpler and more manageable solution.
Have you looked at this tutorial? It gives possible use cases and tutorials for both web and worker roles.
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-dotnet-multi-tier-app-storage-1-overview/
First things first, Hope you all have a good Christmas :)
I've been a desktop application developer for the last couple of years but I'm now working on ASP.NET full time (job move :) )
So over the last few days, I've found my self wondering more and more about what actually happens when say a new visitor will visit my URL..
I've just been working on quite a simple Signal R based app and I have needed a few singletons to be shared across all sessions, now in desktop that's super simple but I'm not sure with the web at all :(
So basically, here is this question..
What actually does IIS do when say 5 people visit my URL, do they all get a separate instance of the app or do they use the same one? If you could break it down into simple terms, that would be fantastic! :)
Also, Say I've got a class library that has a static singleton - with that be the only instance of that class for the all the sessions?
Hopefully that makes sense :)
Thanks for any help!
cheers.
ste.
This is called IIS Life Cycle
The fully details must be direct read from Microsoft and the creators of the IIS.
Is not the same for all IIS.
Life Cycle Overview for IIS 7.0
Life Cycle Overview for IIS 5.0 and 6.0
and there are more if you search on internet.
do they all get a separate instance of the app or do they use the same
one
If you use many pools for the same application (web garden) then they the request are split among the pools, or else one pool, one instance is take care to process the page.
The page can be processing from different threads, but there is a global lock on the session, so if you use the MS session the page will processing in serial (expect the one that did not use session)
Each pool is one instance that hold the static data, and is the same for all request from that pool. If you use two pools you have two different sets of static data.
Some questions about session lock:
Trying to make Web Method Asynchronous , Web app blocked while processing another web app on sharing same session
If you have a default IIS install then you will have one app pool which will serve all requests. Therefore a static singleton will be shared by all 5 people in your example.
BUT if you ever need to scale out then you will have multiple app pools.
An app pool is an instance of your application.
If the statics are for database connections and similar then I would suggest you look at alternative methods so you don't need the statics. If it is something related to the business that your users are interested in then you would be best looking at other ways to share this between clients if you are going to need to scale.
I have downloaded TheWorldsWorstStackOverflowClone. One of the project is called TheWorldWorsts.ApiWrapper, which basically is the core of accessing the API. There is a class called ApiProxy.cs, which has all the methods for the API call. This is good.
Now what I want to do is I am trying to collect data from this API interface and store it in a database. I know the limit to the API call is 10k per day. I.e: I want to be able to call the method in the ApiProxy class 10k times per day, done automatically. How can I do this?
The non-automatic way would be to create a dummy site where when every time I access the site it does all that process, but this not efficient. It seems that I have to write some kind of a scheduler by deploying a web service, but that is too complicated... as explained here. Any other simpler methods?
A Windows Service or Desktop App might be a better solution than a web application. You are not deploying a web service, you are consuming one using a proxy class, and this does not require you to have a web server or a web site.
You could use a web application to control and monitor progress as your service downloads data, but the actual work is long running and needs to be offloaded to another process or thread so you can tell the user whats going on.
Check out this one
http://stacky.codeplex.com/
This looks what you need, though I am facing some debugging issues, but hope you can figure it out.
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'll try to be brief.
What is the best practice for calling a routine from an asp.net web application that initiates a lengthy 'background' process that must be run?
For example, I want to click a button on my webpage that says "Run data conversion" (for example). This data conversion routine may take 20-40 minutes to run, so it seems to me putting all that code into a asp.net web page is not the way to go....there is no need to run this background process thru the IIS server. A sperate service or app etc seemx the way to go...
The web app, and the background process will both run on my dedicated Win2003 server so I have lots of options - but what is the best one?
If you control the server, I would suggest creating a windows service - take the data conversion task outside of ASP.NET altogether; you wouldn't want ASP.NET restarting halfway through a 40 minutes conversion routine.
There are quite a few options, basically it boils down to you needing any sort of process that you can communicate with. The options I can think of off the top of my head are; a web-service running under another application pool; a windows service; a command-line process started by your ASP.NET code.
The next question is how to communicate with the other process. If you're using a database you could set up two common-tables that both processes can access. The website would place the request for work into a table that the second process would monitor. A second table could then be used for the results, which the web-site would monitor. Another option would be to use something like the Windows Communication Foundation (WCF) or .NET remoting to send events between the processes.