Thread Pool in ISS Question

If running a .Net application under IIS with 50 simultaneous requests and
each request is trying to use an ASYNC socket what happens to the thread
pool for that application? It appears that there is a maximum of 50 worker
threads in the pool, if all those 50 threads are processing requests how
will the new ASYNC threads get created? Won't this cause a deadlock while
waiting for an free thread, which never occurs?

Can someone explain to me how this works?

--
Bill

David
Thu Jul 01 12:31:45 CDT 2004

"Bill" <msgdev@hotmail.com> wrote in message
news:O9RKKG4XEHA.2388@TK2MSFTNGP11.phx.gbl...
> If running a .Net application under IIS with 50 simultaneous requests and
> each request is trying to use an ASYNC socket what happens to the thread
> pool for that application? It appears that there is a maximum of 50
worker
> threads in the pool, if all those 50 threads are processing requests how
> will the new ASYNC threads get created? Won't this cause a deadlock while
> waiting for an free thread, which never occurs?
>
> Can someone explain to me how this works?
>

There is only one .net ThreadPool per process. So you will want to keep your
hands off the thread pool when running under ASP.NET. Since the thread pool
is a process-level resource you need to be very careful using it in any
multi-appdomain situation. But this is especially so in ASP.NET since the
thread pool provides the ASP.NET worker threads whick handle the user
requests.

That means no async io, no BeginInvoke and no QueueUserWorkItem.

You are free to start a thread to do a background job, or even build your
own thread pool to handle long-running tasks.

David

DavidWilliams
Thu Jul 01 12:39:01 CDT 2004

As I understand it, you are quite correct. IIS hosts it's own copy of the CLR (which handles the threadpool.) Each copy of the CLR has one ThreadPool, of which there is 25 worker threads per CPU. These worker threads are used by application, async requests, and internally by the CLR. If every one of these worker threads are in use, any additional requests (from any source) will go onto a queue and awaits a return of a thread to the pool. It the items that are processing on the threads are not real short, you may end up noticing a delay in processing.

Now, the CLR and MOST async calls are over very quickly, so you would have to seriously overload the system to see problems if those are the only onces running from the ThreadPool. If on the other hand, you are using the ThreadPool explicatly or from an async call that you KNOW will be long running, then you can run into problems.

What I have done in the past when handling this type of problem is to create my own thread in the Async call. That thread then does the work, while returning the async thread to the pool.

HTH
--
David Williams, VB.NET MVP


"Bill" wrote:

> If running a .Net application under IIS with 50 simultaneous requests and
> each request is trying to use an ASYNC socket what happens to the thread
> pool for that application? It appears that there is a maximum of 50 worker
> threads in the pool, if all those 50 threads are processing requests how
> will the new ASYNC threads get created? Won't this cause a deadlock while
> waiting for an free thread, which never occurs?
>
> Can someone explain to me how this works?
>
> --
> Bill
>
>
>

Bill
Thu Jul 01 13:34:07 CDT 2004

Let me tell you the situation that is giving me a problem. Currently the
Socket functions like Connect() and GetHostByName() do not have timeout
values that can be set. So in order to have a valid timeout value I need to
use the ASYNC version so that it can be manually canceled. Is there anyway
to get around using ASYNC calls but still have the ability to control the
timeout? I am noticing after so many concurrent connection attempts they
start failing because (I think) there are no more threads available to
process the request.


Bill

"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:e5tJJF5XEHA.808@tk2msftngp13.phx.gbl...
> "Bill" <msgdev@hotmail.com> wrote in message
> news:O9RKKG4XEHA.2388@TK2MSFTNGP11.phx.gbl...
> > If running a .Net application under IIS with 50 simultaneous requests
and
> > each request is trying to use an ASYNC socket what happens to the thread
> > pool for that application? It appears that there is a maximum of 50
> worker
> > threads in the pool, if all those 50 threads are processing requests how
> > will the new ASYNC threads get created? Won't this cause a deadlock
while
> > waiting for an free thread, which never occurs?
> >
> > Can someone explain to me how this works?
> >
>
> There is only one .net ThreadPool per process. So you will want to keep
your
> hands off the thread pool when running under ASP.NET. Since the thread
pool
> is a process-level resource you need to be very careful using it in any
> multi-appdomain situation. But this is especially so in ASP.NET since the
> thread pool provides the ASP.NET worker threads whick handle the user
> requests.
>
> That means no async io, no BeginInvoke and no QueueUserWorkItem.
>
> You are free to start a thread to do a background job, or even build your
> own thread pool to handle long-running tasks.
>
> David
>
>

David
Thu Jul 01 15:44:18 CDT 2004


"Bill" <msgdev@hotmail.com> wrote in message
news:%23tcvAo5XEHA.4092@TK2MSFTNGP11.phx.gbl...
> Let me tell you the situation that is giving me a problem. Currently the
> Socket functions like Connect() and GetHostByName() do not have timeout
> values that can be set. So in order to have a valid timeout value I need
to
> use the ASYNC version so that it can be manually canceled. Is there
anyway
> to get around using ASYNC calls but still have the ability to control the
> timeout? I am noticing after so many concurrent connection attempts they
> start failing because (I think) there are no more threads available to
> process the request.
>
>

I believe that Socket.BeginConnect will use blocking socket, callback
function and a worker thread from the .net thread pool.

But winsock has non-blocking sockets, which is a different story. I believe
that you can make a non-blocking connect using a non-blocking socket and
poll the result. I've never done it, but the functionality is there.

David

Tomas
Thu Jul 01 23:06:02 CDT 2004

Hi all,


> Now, the CLR and MOST async calls are over very quickly, so you would have
to seriously overload the system to see problems if those are the only onces
running from the ThreadPool. If on the other hand, you are using the
ThreadPool explicatly or from an async call that you KNOW will be long
running, then you can run into problems.

David's right on this one. One thing I'd point out, though, is that it is
possible to shoot oneself in the foot, though (I've managed it once or twice
;). Be careful of doing async calls from threads already running in the
pool, since that can easily lead to a deadlock situation in which you
saturate the pool in such a way there's no way to move on...

--
Tomas Restrepo
tomasr@mvps.org

Jason
Fri Jul 02 06:53:56 CDT 2004

in any case - the top and bottom of all of this is that anyone can bring a
web server to its knees. there is one threadpool for any number of
appdomains in one process. that is a serious issue for hosting. that
aside - the threadpool is extremely useful for scaling which is why it is
implemented the way it is by microsoft. they did tests to show that 1000
applications could be run inside one process - albeit not as efficiently as
they would have liked. the downside is - that other peoples code can stop
your application. that is pretty silly.


"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:eM20qn#XEHA.3300@TK2MSFTNGP09.phx.gbl...
> Hi all,
>
>
> > Now, the CLR and MOST async calls are over very quickly, so you would
have
> to seriously overload the system to see problems if those are the only
onces
> running from the ThreadPool. If on the other hand, you are using the
> ThreadPool explicatly or from an async call that you KNOW will be long
> running, then you can run into problems.
>
> David's right on this one. One thing I'd point out, though, is that it is
> possible to shoot oneself in the foot, though (I've managed it once or
twice
> ;). Be careful of doing async calls from threads already running in the
> pool, since that can easily lead to a deadlock situation in which you
> saturate the pool in such a way there's no way to move on...
>
> --
> Tomas Restrepo
> tomasr@mvps.org
>
>

Tomas
Sun Jul 04 13:39:06 CDT 2004

Hi Jason,

> in any case - the top and bottom of all of this is that anyone can bring a
> web server to its knees. there is one threadpool for any number of
> appdomains in one process. that is a serious issue for hosting. that
> aside - the threadpool is extremely useful for scaling which is why it is
> implemented the way it is by microsoft. they did tests to show that 1000
> applications could be run inside one process - albeit not as efficiently
as
> they would have liked. the downside is - that other peoples code can stop
> your application. that is pretty silly.

Well, it is an risk that will exist in any multithreading implementation!

--
Tomas Restrepo
tomasr@mvps.org

Jason
Tue Jul 06 06:58:06 CDT 2004

hi Tomas,

to answer your post: not really- that risk was alleviated by the concept of
the process. the appdomain is different - and now runs the risk stated.


"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:eYAfxYfYEHA.2344@TK2MSFTNGP11.phx.gbl...
> Hi Jason,
>
> > in any case - the top and bottom of all of this is that anyone can bring
a
> > web server to its knees. there is one threadpool for any number of
> > appdomains in one process. that is a serious issue for hosting. that
> > aside - the threadpool is extremely useful for scaling which is why it
is
> > implemented the way it is by microsoft. they did tests to show that
1000
> > applications could be run inside one process - albeit not as efficiently
> as
> > they would have liked. the downside is - that other peoples code can
stop
> > your application. that is pretty silly.
>
> Well, it is an risk that will exist in any multithreading implementation!
>
> --
> Tomas Restrepo
> tomasr@mvps.org
>
>

Bill
Tue Jul 06 10:57:52 CDT 2004

If anyone has an example using nonblocking sockets in .Net with proper
timeout's and cleanup implemented I would appreciate seeing it.

Thanks.


"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:%23RkXvw6XEHA.1652@TK2MSFTNGP09.phx.gbl...
>
> "Bill" <msgdev@hotmail.com> wrote in message
> news:%23tcvAo5XEHA.4092@TK2MSFTNGP11.phx.gbl...
> > Let me tell you the situation that is giving me a problem. Currently
the
> > Socket functions like Connect() and GetHostByName() do not have timeout
> > values that can be set. So in order to have a valid timeout value I
need
> to
> > use the ASYNC version so that it can be manually canceled. Is there
> anyway
> > to get around using ASYNC calls but still have the ability to control
the
> > timeout? I am noticing after so many concurrent connection attempts
they
> > start failing because (I think) there are no more threads available to
> > process the request.
> >
> >
>
> I believe that Socket.BeginConnect will use blocking socket, callback
> function and a worker thread from the .net thread pool.
>
> But winsock has non-blocking sockets, which is a different story. I
believe
> that you can make a non-blocking connect using a non-blocking socket and
> poll the result. I've never done it, but the functionality is there.
>
> David
>
>
>

Tomas
Tue Jul 06 20:13:20 CDT 2004

Hi Jason,

> to answer your post: not really- that risk was alleviated by the concept
of
> the process. the appdomain is different - and now runs the risk stated.

Ahh, true, but I thought we were discussing multithreading, not the whole
concept in general.

That said, you are true, and the issue spans far more than just
multithreading... cross-appdomain memory access comes to mind as another.
THis is one of the issues why Windows 2000 is such a poor platform for
ASP.NET hosting scenarios. It takes IIS 6.0' AppPools to make this right
again...

--
Tomas Restrepo
tomasr@mvps.org

Jason
Wed Jul 07 09:15:50 CDT 2004

agreed :)

"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:u9QPc#7YEHA.4008@TK2MSFTNGP09.phx.gbl...
> Hi Jason,
>
> > to answer your post: not really- that risk was alleviated by the concept
> of
> > the process. the appdomain is different - and now runs the risk stated.
>
> Ahh, true, but I thought we were discussing multithreading, not the whole
> concept in general.
>
> That said, you are true, and the issue spans far more than just
> multithreading... cross-appdomain memory access comes to mind as another.
> THis is one of the issues why Windows 2000 is such a poor platform for
> ASP.NET hosting scenarios. It takes IIS 6.0' AppPools to make this right
> again...
>
> --
> Tomas Restrepo
> tomasr@mvps.org
>
>

Bill
Thu Jul 08 15:48:13 CDT 2004

What about GetHostByName() there is no nonblocking call for this. How do
you control the timeout under IIS without using BeginGetHostByName?


"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:%23RkXvw6XEHA.1652@TK2MSFTNGP09.phx.gbl...
>
> "Bill" <msgdev@hotmail.com> wrote in message
> news:%23tcvAo5XEHA.4092@TK2MSFTNGP11.phx.gbl...
> > Let me tell you the situation that is giving me a problem. Currently
the
> > Socket functions like Connect() and GetHostByName() do not have timeout
> > values that can be set. So in order to have a valid timeout value I
need
> to
> > use the ASYNC version so that it can be manually canceled. Is there
> anyway
> > to get around using ASYNC calls but still have the ability to control
the
> > timeout? I am noticing after so many concurrent connection attempts
they
> > start failing because (I think) there are no more threads available to
> > process the request.
> >
> >
>
> I believe that Socket.BeginConnect will use blocking socket, callback
> function and a worker thread from the .net thread pool.
>
> But winsock has non-blocking sockets, which is a different story. I
believe
> that you can make a non-blocking connect using a non-blocking socket and
> poll the result. I've never done it, but the functionality is there.
>
> David
>
>
>