asp.net infinite loop - can this be done?

This question is about limits imposed to me by ASP.NET (like script timeout etc').

I have a service running under ASP.NET and I want to create a counterpart service for monitoring.

The main service's data is located at a database.

I was thinking about having the monitor service query the database in intervals of 1 second, within a loop, issued by an http request done by the remote client.

Now the actual serving of this monitoring will be done by a client http request, which will make the script loop (written in C#) and when new data is detected it'll aggregate that data into that one looping request output buffer, send it, and exit the loop, thus finishing the request.

The client will have to issue a new request in 开发者_运维百科order to keep getting updates.

This is actually exactly like TCP (precisely like Windows IOCP); You request the service for data and wait for it. When it arrives you fire another request.

My actual question is: Have you done it before? How did it go? Am I limited by some (configurable) limits imposed by the IIS/ASP.NET framework? What are my limits in such situation, or, what are better options without complicating things too much?

Note that I do not expect many such monitoring requests at a time, maybe a few dozens.

This means however that 10 such concurrent monitoring requests will keep 10 threads busy, and the question is; Can it hurt IIS/performance? How will IIS handle 10 busy threads? Will it issue more? What are the limits? This is just one example of a limit I can think of.

I think you main concern in this situation would be timeouts, which are pretty much configurable. But I think that it is a wrong solution - you'd be better of with some background service, running constantly/periodically, and writing the monitoring data to some data store and then your monitoring page would just return it upon request.

if you want your page to display something only if the monitorign data is available- implement it with ajax - on page load query monitoring service, then if some monitoring events are available- render them, if not- sleep and query again.

IMO this would be a much better solution than a reallu long running requests.

I think it won't be a very good idea to monitor a service using ASP.NET due to the following reasons...

1. What happens when your application pool crashes?

2. What if you decide to do IISReset? Which application will come up first... the main app, or the monitoring app?

3. What if the monitoring application hangs due to load?

4. What if the load is already high on the Main Service. Wouldn't monitoring it every 1 sec, increase the load on the Primary Service, as well as IIS?

You get the idea...