ASP.NET Comet fixes

Trying to locate and correct a problem in an open source ASP.NET Comet implementation. Original author is unable to help me. Basic problem is sudden high CPU consumption by the IIS worker thread pool ([login to view URL]) which is causing what appears to be an unusual race condition. The end result is that Comet subscriber clients get artificially removed via an incorrect idle timeout, after the beginning of a subscribe event but before the subscribe event completes. Relevant original source code is at the following; [login to view URL] I have also my current working version available, which has a number of minor bug fixes and some debug statements to try to locate the problem, though it probably won't be of much of help. Additional work is trying to correct most of the problems pointed out by FxCop. ## Deliverables I am able to recreate the problem in two environments; 1. VMware virtual machine containing a fully patched Windows 2003 japanese install with IIS, .NET 2/3/3.5 installed and updated. Virtual machine has 1GB of RAM 2. A P4 hyperthreaded Dell poweredge server with 1GB RAM, same software load as #1 but with Exchange 2003 installed (running but otherwise unused) Best as I can tell, something strange happens that holds up the idle timeout detection. When the client resubscribes, the beginning of the event is okay, but then the idle timeout finishes and removes the client instance from the instance manager. As the subscribe event finishes it's tasks, the instance manager has an exception because the client no longer exists, aborting the subscribe event. This usually occurs when there are 4 or more clients subscribed. It doesn't seem to make a difference if you have 4 browser tabs open on one computer or connecting from 4 different computers. The problem has a higher chance of occurring when a chat message is posted, but it still occurs randomly when no messages are being posted. Running the debug build for some reason locally from visual studio 2008 reduces the chances of the problem occurring substantially. The problem is more likely to occur on the normal servers. I usually try to do remote debugging to try to watch what is happening. I have attached my current working version. It has some small fixes regarding URL handling (original version was stuck exclusively to the default website root), and some debug statements to get a feel for the overall flow. The previous version of this software (The part 1 version at [login to view URL] claims 5 threads handling 200 concurrent connections, and not blowing out the main ASP.NET worker thread pool. I have a long term goal of an IIS ASP.NET Comet implementation trying to handle 4000 concurrent connections, but I don't know if the current design of the in memory instance handler can really scale that far. A colleague said it may be better to scrap about half the overall design and switch to a semaphore based system for handling events. There may be some merit to that idea, but I don't know enough to say if that's the end solution.