I want to add a scheduled task to a client's ASP.NET app. These posts cover the idea well:
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
What is the Best Practice to Kick-off Maintenance Process on ASP.NET
"Out of Band" Processing Techiniques for asp.net applications
My question has two parts: First, will IIS unload the application if there isn't enough request activity despite the Cache activity? My client doesn't enjoy as much traffic as stackoverflow so they can't rely on user requests to keep the app 'active'. Obviously, I can't schedule tasks in an unloaded app.
Second, if so, is there a way to prevent IIS from unloading the app outside of configuration or external 'stay-alive' requests? My client's host doesn't allow much configuration tweaking and a stay-alive utility introduces the deployment complexity I'm trying to avoid with an ASP.NET Cache solution.
Thanks a bunch.
Edit/Conclusion: TheXenocide's solution is exactly correct given the question. However, I've decided it is a really bad question. The temptation to cut corners is always looming. I've regained my senses and told my client to use a website monitoring tool to keep the site active. In addition, the scheduled task is going in a windows service despite the extra deployment hassle.
Unfortunately, outside the range of changing timeout configuration (which I believe to be possible in Web.config, though I don't know what is and isn't allowed on hosting providers, most of which use Medium Trust) I don't believe there is any other method to keep the application from ending beyond web requests. One thing you might try that may be a little more simple than using some keep-alive service on a local machine might be to add some logic to Session_Start/Session_End that ensures there is always at least one session active; you can use the WebRequest class from within your application to call your own site and it should still start a new session.
Good luck, and let us know what you do :)
UPDATE: these details now very much depend on which version of IIS and which version of .NET you're running in. Newer versions of each have methods of configuring "always running" applications.
Related
I have to see if I can work around a known thread safety issue on third party component. The plan was to let an ASP.Net app to talk to the third party component via a WCF service, this was based on the assumption that I will be able to assign the WCF service to it's own application pool, restrict the pool to one working process and the working process to one thread. Requests to the service will have to wait for their turn, but that's OK because we expect them to require very little time and to be rare as well.
Problem is, I can't find anything that suggests how to achieve this part: "restrict the working process to one thread".
I have found a few useful pages, but no solution:
On IISforums, the discussion seem to suggest that I can achieve this in IIS 7+ but does not mention IIS6.
On MSDN Blogs and linked MSDN books chapter (can't put the link because I'm new here!) the discussion is mostly about what you can set via the machine.config file, which, if I'm understanding it correctly, is going to apply to all AppPools/Worker processes and is not what I'm trying to do, I would like to control what one single app can do, leaving the other applications untouched.
Questions:
Is it possible to achieve what I'm trying to do? (assign the WCF service to it's own application pool, restrict the pool to one working process and the working process to one thread" via IIS 6 configurations)
If not, can this be achieved programmatically somehow? For example, using locks or other threading-related tricks within my WCF service implementation.
It doesn't make much sense to me.. A web server have to be multithreaded by definition, because it must handle different income messages at the same time, if there is only one thread once in use any new request will fail.
What about to wrap the component in a class with a SynchonizationAttribute, so only one thread can access the component? Even if this will make your solution less scalable, at least it may work
http://msdn.microsoft.com/en-us/library/system.runtime.remoting.contexts.synchronizationattribute(v=vs.110).aspx
We are referencing a 3rd party proprietary CLI DLL in our .net project. This DLL is only an interface to their proprietary C++ library. Our project is an asp.net (MVC4/Web API) web application.
The C++ unmanaged library is rather unstable. Sometimes it crashes with e.g. dangling pointers. We have no way of solving it, and using this library is a first-class customer requirement.
When the application crashes, the application pool in IIS doesn't respond anymore. We have to restart it, and doing so takes a couple minutes (yes, that long!).
We would like to keep this unstable DLL from crashing our application. What's the best way of doing it? Can we keep the CLI DLL in a separate AppDomain? How?
Thanks in advance.
I think every answer to this question will be some kind of work around.
My workaround would be to not interact directly with the DLL from your web application.
Instead write your requests from the web application to either a Message Queue or a SQL table. You can then have another application such as a Windows Service which reads the requests, interacts with the DLL and then writes the results back for your web application to read.
I'm not saying that SQL / Message Queues are the right way, I'm more thinking of the general process flow.
I had this exact problem with a third party library that accessed protected memory for purposes of interacting with a hardware copy protection dongle. It worked fine in a console or winforms app, but crashed like crazy when called from an IIS application.
We tried several different things, some of which are mentioned in other answers on this page. But ultimately, the best solution for us was to us a very old technology - .Net Remoting. I know - it's somewhat frowned on these days. But it fit this particular need quite well.
The unstable code was placed in a Windows Service application. The web application made remoting calls to this service, which relayed the commands to the third-party library.
Now I'm sure you could do the same thing with WCF, sockets, etc. But remoting was quick and easy to setup, and since we only talk to the same server it works without opening any ports. It just talks on a named pipe.
It does mean a second service to install besides the web application, but that was acceptable in my particular use case.
If you did something similar, and the third-party code actually crashed the service, you could probably write some code in your main application to bring it back up.
So perhaps a process boundary is more useful than an App Domain when you have unstable code to wrangle.
I would first increase the IIS process recyling rate, maybe the the DLL code fails after a certain number of calls, or after the process reaches a certain amount of memory usage.
You can find information on the configuration of IIS 7.0 recycling options here: http://technet.microsoft.com/en-us/library/cc753179(v=ws.10).aspx
In your case I would recycle the process at a specific time, when you know there is less load on the application. And after a certain number of requests (lower than the default) to try and have "fresh" process most of the time.
The recycling process is graceful in the sense that the the old process is not terminated until the one that will replace it is ready, so there should be no noticeable downtime.
More information about the recycling mechanism here: http://technet.microsoft.com/en-us/library/cc745955.aspx
If the above does not solve the problem I would wrap the calls in my own code that manages the unstable DLL execution.
This code should recover from the failures for example by repeating the failing calls until a result is obtained and failing with a graceful error if it is not possible after a number of attempts.
Internally the calls to the unstable DLL could be made in a spawned thread or even the code could be in an new external executable that you could launch with Process.Start.
This last option has more overhead but it might be your only option. See this SO question for more information on this: How do you handle a thread that has a hung call?
I suggest following solution.
Wrap this dll with another web application. Can be one of the following ones. Since you already use web api, it is most suitable for you.
Simple ASMX Web Service
WCF Service
Asp.Net MVC - WEB Api Service
Control your p-invoke code so that you do not have any bug? See following articles.
The Black Art of P/Invoke and Marshaling in .NET
P/Invoke Revisited
Publish this application to IIS with different application pool.
Use standard techniques suggested before like. I suggest configure recycling IIS for both memory and scheduled times.
IIS process recycling rate
How to limit the memory used by an application in IIS?
Our company releases updates of our rich client application (written mainly with ASP.NET, WCF services, and ASP.NET AJAX) on our client's Windows Server 2008 IIS 7 web server. Once in awhile, we have large releases of updates. And sometimes there are bugs that users catch right after the release that are not caught during automation testing nor stage testing. Is there a way to smoothly deploy ASP.NET code on IIS 7 while users are still on without disrupting their workflows containing code that was not affected? I've found that if I just copy the code from stage (without the web.config) manually, and paste it into the production web root folder, nobody is really kicked off. But I'm wondering if there are any side-effects to this strategy for users diligently working in the application. I'm just wondering if any other connections may get interrupted or how they're even handled in this situation (ie: SQL connection, WCF Service calls, whether they keep the same session and if that will have any impact, etc..)? If I chose this method, I'd have something in the web.config that would display a message to every user (in the master page)--like a banner, that says "Please log off, and clear your cache", so they would see updates to issues addressed. But this would only be relevant to the impacted users.
If someone doesn't think this is a good strategy for minor updates, and has a better strategy, like changing a web.config setting that forces the user to a different server or something while the deployment is taking place. Or some other methodology, my ears are listening. Obviously the latter sounds safer, but I just don't know how this could be done. I've read about load balanced servers, but I think this type of server setup is done for different purposes, like if a server goes down, doesn't it? Or would this be the best solution as you take one site down? I'm welcome to any idears.
I used to stress about minimal-impact for releases too, but now we take it down. The reality is twofold:
You cannot guarantee that everything someone is working on right now is NOT something you're about to update. Consider this: A user is working on x.aspx and is in the middle of a postback. You drop a new x.aspx.
With enough notice, maintenance windows are a way of life. Users should expect that, from time to time, you need exclusive access to the application to make updates, etc.
It's just too hard to keep all the plates in the air when you really don't know what someone might be working on while you deploy. Especially if database updates are in the mix!
If there is a load balancer in the mix: you would remove the server(s) with the old code and add add the server(s) with the new code. This lets the traffic die out on the old code servers without kicking people out. The new server(s) picks up the traffic.
We do this with a new release to one server at a time until we replace all of the code in our server farm. It gives the application time to bake in the real world. If issues comes up, and they have, you only have to revert a single server. using the load balances makes it easier.
It is (usually) a seamless transition. Of course you need to make sure you app can handle any database changes etc.
I make an application for querying from and inserting data to the database using ASP.NET 3.5 linq to SQL.
It works fine in the development server.
But after deploying to the staging server, after the first few requests, the application seems unresponsive no matter what I type in the URL. The whole IIS application is frozen. I know I can restart the application to fix that. But I don't want it to happen again in the future.
What are the possible causes of this?
I've just found a ref about this problem:
http://blogs.msdn.com/lucascan/archive/2009/04/14/troubleshooting-an-unresponsive-web-server-iis-part-1-of-2-gathering-the-data.aspx
http://forums.iis.net/p/1154624/1893546.aspx
It's not easy to provide an exact cause since we have no idea how the application was written, what dependencies exist, whether service packs/patches are installed etc. What we could help with is debugging the application.
Things I would start with:
Find out if other applications have the same problems.
Review the server event logs on both servers.
Memory, CPU usage etc on the server with Performance Monitor (perfmon.exe)
See what SQL is being generated with SQL Profiler.
Use an HTTP Analyzer like Fiddler to find out if the server is running anything in particular but the browser is not displaying it.
As BrianLy says this is one of those tricky to pin down situations. We had several problems with ASP.NET apps taking seemingly forever to start, this was down to our corporate firewall blocking crl.microsoft.com.
It's probably a stab in the dark, but it might be worth investigating. The chances of your issue being this sound slim though.
A quick test to see if it is something related to this is to add 127.0.0.1 crl.microsoft.com to your hosts file.
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.