ThreadPool and contacting remote resources

[Trebek]

Hello group:

I have a quick question.

Background:
I have an assembly that is responsible for handling our clients' *requests*
(not a webservice/http request per se but our concept of a request --
meaning 'request for our service') thru our webservice. Depending on the
type of client request, we may have to contact an outside provider thru a
WebRequest/WS-method, DCOM, etc... The way it works currently is to handle
all the request parsing/db work/etc. in the main thread, and, if any
outside requests are required, start a thread to handle them. The client's
webmethod response is not dependent on the 'outside' request completing
(some of them can take a few seconds and the client could pair several of
these together so we don't want their response to be waiting on the
completion of these outside calls) so we just return a webmethod response
saying 'we recieved the request, this, that and the other thing'. The
system has been up and running in this fashion for 2 years and threading
deadlocks/contention is not an issue under the current system load.

Recently, we re-wrote this portion of the system to reflect better
efficiency and I'm to the part where I spawn these 'outside' requests. Due
to an increase in business, we have had to offer additional business
services all featured under the same server (to use the branding of the
domain name) because of the SSL cert being paired to the ws address and, for
the first time, server resources have started to become an issue. Hence the
need for the rewrite.

Question: Should I be queuing these 'outside' requests in the ThreadPool?
I know that the ThreadPool class is used internally by various .NET classes.
I would guess that a possible race condition could occur if our client's
request happened at a time when the ThreadPool's max threads are close to
full utilization and their request would require the runtime to use
ThreadPool threads to service a webrequest exceeding the max threads in the
pool. Does anyone know if this is true? By and large, the client requests
complete quickly enough that this *probably* wouldn't occur, but, in the
interest of shoring up my application as well as servicing increased
business, it could potentially occur. We cannot limit the client service
requests in any way (business requirement).

What is the best way to handle this situation?

Thanks all,

Alex

 

[William Stacey [MVP]]

I would have one object that is your ClientWorker. That contains its own
thread. ClientWorker will also have a blocking bounded buffer (cQueue) that
listener puts requests into. Your worker thread will block waiting for an
Enqueue (i.e. data to work on.) Then your not messing with threadpool and
delegates, etc. You have one thread that goes full blast picking off
objects and sending replies. If you needed other async work within the
worker (such as name lookups, etc) you could use thread pool - this would
all depend on what your doing and not enouph info yet to know. Anyway see
http://www.codeproject.com/csharp/BoundedBlockingQueue.asp for an example
network/listener/worker using this queue method. hth

 

[Robert Jordan]

Hi Alex,

Question: Should I be queuing these 'outside' requests in the ThreadPool?
I know that the ThreadPool class is used internally by various .NET classes.
I would guess that a possible race condition could occur if our client's
request happened at a time when the ThreadPool's max threads are close to
full utilization and their request would require the runtime to use
ThreadPool threads to service a webrequest exceeding the max threads in the
pool. Does anyone know if this is true? By and large, the client requests
complete quickly enough that this *probably* wouldn't occur, but, in the
interest of shoring up my application as well as servicing increased
business, it could potentially occur. We cannot limit the client service
requests in any way (business requirement).

We were unsucessfully using the ThreadPool in conjuction
with the HttpWebRequest class. HttpWebRequest uses the ThreadPool
itself and doesn't cope at all when the pool is going out
of threads. Instead of accepting that the request has to be
queued, HttpWebRequest throws an exception (.NET 1.1).
We end up implementing our own thread pool.

Bye
Rob

 

[Trebek]

Thank you both ... I'll look into that sample.


Alex