[Mono-dev] .Net 2.0 asynchronous web pages

[Sunny]

On 9/11/07, Konstantin Triger <kostat at mainsoft.com> wrote:
> The feature actually consists of 2 sub-features:
> 1. Runtime support (Page API).
> 2. Aspx parser support.
>
> Several months ago we completed (1). So currently someone needs to ensure (2) works too.
> While implementing it, we did not find any really useful scenario why someone may need this feature. Can you please explain what your use case is?

Hi Kosta,
the scenario is the same as with async web services - to free a
threadpool thread not to be used for a long term operations.

I have a web page (I can use web service, but it returns a blob of 1M
binary data, so with soap, etc, it will be at least doubled) which
returns a blob of binary data, which is collected after a lot of web
service and database requests in different threads (async, so io
threads from the thread pool). When you have too many incoming
requests, which block for a long time thread pool threads, and in the
same time your execution occupies thread pool threads for the outgoing
requests, the result may be a dead lock, and dropped requests, because
no one knows the order of thread assignment (i.e. the order in which
you will receive incoming requests, and when your own requests will
start). As elementary example (thread pool with only 4 threads):
- receive first request and block untill finish - 3 in the pool
- receive sec. request and block - 2 in the pool
- first req. starts 3 own threads to get data - they in term need 3
thread pool threas - 2 are available, and one queued
- third request is received, and queued (not pool threads)
- forth request is received, and queued (not pool threads)
- fifth request is received, and queued (not pool threads)
- second req. starts 3 threads as well, and the framework queues them
- one of the requests from the first request is finished and thread
pool thread is freed
- it is assigned to the third call made by the first request
- next req. finishes, and the thread is assigned to the third incoming
request, and block, because its processing stops to wait thread pool
threads (3 of them).
- now, when the 3th thread from the first incoming is finished, it
will go to the forth incoming request and blocked

now you have your thread pool blocked on requests, which in terms wait
on the tread pool. Eventually this will end with some time-outed
requests, but may end with really bad dead lock.

That's why using async web services is good for such a scenario, and
because I need web page instead web service, I need the async
approach.

Of course, there are online some examples how to do this with 1.1 and
creating your own aspx handler, so you make the call async.

And, of course, maybe I can rethink the design. But lets say that this
is the approach which serves me best.

Basically, I have the application, implemented for 2.0, and now I just
have to decide what server to use - win or linux. And I would prefer
linux. So, maybe I'll go with some of the workarounds, i.e. to
implement my own handler, or I may wait some time, if this is planned
feature.

For reference:
<http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/>

And this is a comparison in the performance when using async vs sync
pages, when the page logic makes a lot of async requests itself:
<http://www.pluralsight.com/blogs/fritz/archive/2004/10/19/2892.aspx>

Pls, note, that I could not find the original article I read about the
dead blocking scenario, so I just tried to reproduce it (maybe
inaccurate).

Cheers

-- 
Svetoslav Milenov (Sunny)

Even the most advanced equipment in the hands of the ignorant is just
a pile of scrap.