Keep a WCF Service alive under IIS

Question

i have thoroughly searched the internet (most of the links sent me to stackoverflow ;)) to try to come up with a solution how to keep a WCF Service alive under IIS (7.5).

Many of the responses here were suggesting to write an application that will periodically send dummy requests to the WCF service in order to keep it alive.

My question is: what if I create a thread in the WCF which will start when a service is first called (in a static constructor) that will periodically consume the WCF itself?

I mean for example in c#:

while (true)
{
     WebClient client = new WebClient();
     string returnString = client.DownloadString("http://...");
     Thread.Sleep(1000 * 5);
}

assuming that "http://..." is an URI to a provided WebMethod which for example returns some integer.

Would that work?

Basically I need some kind of web service (not particulary a WCF but not a Windows Service) that is running on a server that performs some operations and updates something in a SQL Server database. So if the described approach will not work, what might be the best way to achieve this?

Answer 1

Go to your IIS -> Application Pool (or create new one) -> Advanced settings and set Regular Time Interval=0

See related thread here.

Answer 2

AppFabric allows you to create wcf services which can autostart and be long living - this might be worth checking out as a hosting option (it's just a plugin for IIS)

Auto Start

Answer 3

What you are doing is basically wrong from the outset.

The problem is this: IIS is basically a stateless request broker for http requests (basic IIS) and a request broker for service requests (IIS w. AppFabric).

What you are asking for is how to turn the inherently stateless IIS into a stateful server, with eternal threads running.

That is not what IIS does, IIS handles requests and its AppDomain is subject to AT ALL TIMES be torn down (destorying all threads).

Which makes the most upvoted answer dangerous, as it teaches you how to affect the recycle process, without controlling the tear-downs (off app-domains and threads) that IIS itself will intermittenly perform.

The requester is "foreign" to the IIS itself.

The internal lifetime of the service though, is entirely managed by IIS (and the configuration of its applications) itself.

So if with "keep alive" you mean: to constantly request some service, then do as Andreas suggest further up (create a schedueled job).

If with "keep alive" you mean: to make sure the same instance of the class handles requests, then you need to look into WCF lifetimes.

If with "keep alive" you mean: to make the code you have created "stateful" and keep f.eks static variables alive and so on, well you are not accepting that IIS is basically a stateless pr. request broker with internal lifetime management.