Chris said:
I have an ASP.Net page which does some very memory intensive GDI+
processing. This page is being called using AJAX by another script
which I have no control over. What is happening is that the consuming
script is attempting to call my page hundreds of times which is causing
'Out of Memory' exceptions.
Is there any way I can change the behaviour either in my code or in IIS
to throttle the connections but keep them in a queue of some sort? I
can handle maybe 10 requests at a time, but I would want to queue up
requests in excess of this to be processed in order rather than give
timeout errors. This needs to be handled from my end rather than the
AJAX script end. Is this possible?
Certainly it should be possible. I had a system where I had to slow
down my response based on how many bad attempts had come from a
particular IP address, but obviously not tie up the servers threads by
having them sit in a Thread.Sleep or equivalent. All parlance below is
VB, but if you're in C# it should translate.
My page implements IHttpAsyncHandler. I have a Shared Sub New which
creates a queue (I use SortedList in my implementation, Queue is
probably more appropriate for you) and a thread. This thread sits in a
loop (with suitable sleeps when idle) and scans the queue for requests
to process (in my case, to see if they've been sat waiting long
enough). It then takes the requests off of the queue and processes
them.
The BeginProcessRequest function (part of IHttpAsyncHandler) takes the
details of the request, puts them into an object that implements
IAsyncResult, and it is these objects which are queued onto the above
mentioned queue (they store the context and the Me reference).
EndProcessRequest is empty, as is ProcessRequest. A helper function
takes the dequeued request and uses the stored Me reference to find the
page object. It then calls MyBase.ProcessRequest on the context which
was initially passed to BeginProcessRequest.
As you can hopefully see, the above model decouples the incoming
requests to their time of processing, but uses the normal ASP.Net
system (process request) to perform the normal processing.
What would you need to do for your system to work? Well, I'd recommend
that instead of one thread sitting and looping, you use 10 (or however
many you find is the right number - make it parameterisable).
Pseudocode of the thread body would be
While notAborted
Wait on "somethings arrived" autoreset event
While finding things to do
Synclock the queue
Check if there's a request on the queue.
If there is, dequeue it
End Synclock
If we dequeue a request, go to processing
End While
End While
And then the enqueueing code looks like this
Synclock the queue
Enqueue the request
Set the "somethings arrived" event
End Synclock
Course, you're still going to face memory issues, even doing this,
since every pending request has to have it's page object and context in
memory.
Another route might be to write a HttpModule which will intercept
things earlier in the process pipeline (before these objects are
allocated), and use shared state to know how many requests are
currently executing (so hook up event handlers to BeginRequest and
EndRequest, and if it's for the page that needs protecting, determine
how many requests are currently being processed, send it to sleep by
some suitable mechanism until one of those pages hits EndRequest (maybe
allocate a WaitHandle and put it on a queue again, but watch out for
race conditions)
Damien
