I have written one .Net Application recently which is deployed on IIS. The application is collecting timely data from the data server. Application internally use multiple HTTP connection and application-level caching to improve the application performance.
The recycling is configured with one day interval. I have noticed that whenever IIS manager recycled the service, the newer application does not have any cache data. I have two questions related to this.
Is the case, whenever application get recycled it will not have any cache data which are used on previous instance?
On application recycle, will it release all the HTTP connection which are present on the application.
Also, is there any way to preserve the application state to newly created instance after recycling process happens?
Please let me if any questions are ambiguous.
Related
I have a WCF service application hosted in IIS. On startup, it reads the SQL connection information from the web.config and connects to the SQL Server to get the necessary information to bootstrap the application. If the SQL Server is unavailable for some reason, we want the service to shutdown - which I currently accomplish by throwing an exception.
The problem we have with this is that, if a service fails to start more than N times, IIS helpfully turns off the application pool - which means that, after the SQL Server connection issue is corrected (possibly entirely external to the IIS server), a sysadmin has to think to go an turn the app pool back on.
What I'd like to do is have the service gracefully exit. I know that there are ways to do this with ASP.Net Core (i.e., ways to hook into the lifecycle management of the process and tell it to exit), but have been unable to find anything like that for .Net Framework/ASP.Net.
Is there such an API that I can use?
Turns out that this method is available and works.
https://learn.microsoft.com/en-us/dotnet/api/system.web.hosting.hostingenvironment.initiateshutdown?view=netframework-4.8
We have multiple load balanced IIS web servers for our application backed by a MS SQL server database. We store application configuration information in the database. While the application is running I frequently change the configuration and the changes need to be propagated to the other web servers. Is there a good way to do this? I have been doing it through SignalR (to alert other servers a change has occurred and they should refresh their configuration) but SignalR is not always reliable and sometimes one server does not get the message. Is there a better solution?
Thank you
Updated
I now understand you to need to propagate an application level configuration change.
You could, as you mentioned, use SignalR. This would require having a central server that hosts the websocket connections, but has the benefit of being "instant".
Alternatively, if your requirements are simple, perhaps a short term in-memory cache would suffice.
If it's complex than that, I'd recommend looking into event queues (MSMQ, RabbitMQ). In this model, the instance changing the configuration publishes an event to the queue which can be consumed by the other instances on a background thread.
Original Answer
Microsoft Web Deploy was built to do this. It supports synchronizing sites across servers, even down to application pool settings and SSL certificates.
The IIS documentation site has a specific page that is relevant to your use case: Synchronize IIS.
There is a lot involved in configuring Web Deploy so I won't attempt to explain it all here, but for posterity reasons the command to sync a local site to a remote machine would be:
msdeploy.exe -verb:sync
-source:apphostconfig="Default Web Site"
-dest:apphostconfig="Default Web Site",computername=Server1
(The command was split over multiple lines for readability)
As an an entirely alternative approach, you could also use a "pull configuration" system like Powershell Desired State Configuration or Chef.
I'm currently working on a WCF service which holds and processes all the data for an application, while a MySql database is used for persistence. The service currently works as a singleton (InstanceContextMode.Single) and supports multiple concurrent calls (ConcurrencyMode.Multiple). I'm not really sure what version of IIS the service is hosted in, but I believe it is IIS 7.5.
The problem is that there are some situations where if an exception occurs (eg.: while releasing ReaderWriterLockSlim locks), the service will be in a unreliable state and data may get corrupted (and written into the database) if users keep calling the service.
Currently I know of two ways of preventing users from calling the service: either closing the InstanceContext object (through OperationContext.Current) or raising an exception in IDispatchMessageInspector.AfterReceiveRequest if the service is in a faulted state. The problem with both of these two ways is that they make the service unavailable until I restart the server/application pool (which I can't, see note below) or re-deploy the service.
Important note: Although I have Full-Trust, the service is currently hosted on a shared server, so I can't restart the server or the entire application pool (if that is possible) because that would restart other people's services as well.
Update:
I tried unloading the AppDomain as #usr suggested, but that doesn't work as well: after unloading it, an exception is raised for every call to the service.
Currently I'm trying to find out what WCF/IIS uses as a condition to decide if the service should be created again. I noticed that in the code generated for the client checks if there is any channel available to communicate with the service; if there isn't, a new one is created. Thus, I tried to close all channels in the service: I tried closing OperationContext.Current.InstanceContext.OutgoingChannels, OperationContext.Current.InstanceContext.IncomingChannels, OperationContext.Current.Channel, and many other properties with "Channel" in their name, all of them with no success.
The way to warm-up anything in IIS prior to version 7.5 is using scheduled console application to ping your web site / services and warm them up. It's not a good fix but it works, it is easy and I saw it on every project which had to deal with this requirement.
Or If you are using IIS 7.5 then
You can use Windows Server AppFabric, it has Auto Stat feature to keep the service always on. But you need to be on IIS 7.5 to install App Fabric.
If I create a web application and host it on a Windows Server, then as I understand it, IIS handles the initial request and routes it to the appropriate website or application. I'm under the impression that a w3wp.exe (worker process) instance is created for each application. IIS works with the worker process, which in turn works with the web application.
What happens if the application gets twenty requests per second? Will the worker process create twenty instances of the application to handle each request, or will it queue the requests passing them to a single instance of the application as and when?
I suspect it's the latter. If that is the case then am I right to think that the worker process will keep an application alive whilst it is getting requests?
I'm trying to fully understand what a web application does when it handles many con-current requests. I've tried asking this question before but struggled with the wording, so hopefully this makes sense.
EDIT:
Thanks to Mason I realised that the answer was right in front of me! Web applications use DLLs, which can't run by themselves. It's the w3wp.exe (worker process) which call the DLLs to handle the requests.
The number of worker processes per web site is controlled in the application pool advanced settings (in IIS management console).
The configuration of number of concurrent requests each of the workers can handle depends on the IIS version. In IIS 7 was in the same place, for more recent versions you will have to check your machine.config (looking for maxWorkerThreads)
Question: When a webapplication gets started, it executes Application_Start in global.asax.
Now, a web application gets started as soon as the first request for a page in that application reaches the server.
But my question is: how long will the application run until the application is stopped.
I mean when after the first page request, there's no traffic on the server.
I need to know because I intend to start a server that listens on a tcp port in global.asax.
And when the application stops, the server ceases to listen to its port.
It depends on your IIS settings. Your application will run in an application pool, which takes a bunch of settings defining the behaviour of this pool.
The thing you're looking for are recycling settings. In IIS 7, you can access these easily from the management console. Go to Application Pools, right click on the application pool your app runs in (if you don't know which one that is, then it's probably the DefaultAppPool) and select recycling.
Here you'll find the options you have to control the recycling behaviour of your app pool, which in turn controls when your app 'resets'.
in a word (well 2) - shared hosting.
on shared hosting beware, (godaddy/webhost4life etc) this timeout could well be less, plus you don't have option to configure that on these hosting environments. i've had cases where the app pool is recycled after 5 mins at certain peek times, so you might have to investigate 'wakeup' routines to poke your app to keep in in the memory. i do this for a few shared hosting apps to great effect using pingalive.com.
hope this helps, even if in an abstract way.
jim