Last post Mar 28, 2007 10:14 AM by NozFx
Mar 28, 2007 04:48 AM|NozFx|LINK
I'm designing a ASP.NET application with the use of Asynchronous HTTP Handlers. The reason being that I want to break the rules <g>. What I am trying to design is a handler that will hold onto a request for a long period of time. I mean longer than you
would say is safe for an ASP.NET (or any web application) to hold on to (uh-oh <g>). The reason for this is that I want to provide a simulated PUSH data feature in a windows mobile solution. I'm borrowing this idea from the MS Exchange Team as my research
has discovered that they do it in a similar way to this (with a custom ISAPI application).
My research has also told me that I am safe spawning my own threads using ASP.NET using a Asynchronous HTTP Handlers (over and above a recommended limit) as long as the CPU is not hogged by them. (I realise I have to cap this, as everything is finite). The
flow of these requests would work as the following:
Request -> IIS -> ASP.NET -> Thread from thread pool -> Async Handler -> new thread -> sit in wait-state using thread synchronization (time-out).
Return thread pool thread <---| Respond to client <---|
The thread-sync could be done using something like an AutoResetEvent() with a time-out. The issue I have here is that I need some thread to trigger.Set() for these events in order to free the threads. This would mean what ever process updates the queue
needs to do this. This is an initial problem for me as the code that updates the queue is another process altogether (out-of-process); its not even ASP.NET or .NET.
This leaves me with one other option (other than polling). As the queue is held in a SQL DB I could use a trigger on the queue to call into the ASP.NET application via a HTTP call. I'm not sure how well this will work, to my question; Can I call another
HTTP Handler to trigger these events? How would I register these events in a thread-safe manner? Can this new handler even signal these threads? As long as they are in the same application it would work, wouldn't it? How would I configure this correctly?
Any help or advice would be greatly appreciated.
Mar 28, 2007 10:14 AM|NozFx|LINK
Ok so I put a lot of detail in the first part of this post. Heres a cut down of what I'm after:
If I have a thread created by an Async HTTP handler waiting using an AutoResetEvent. Is it possible to call trigger.set() from another thread spawned later in the same application domain? What I would like to do is free these threads when an another HTTP
request comes in.