CE6: SoapClient Threadpool problem

U

Ulrich Strauss

I have a CF Applikation which talks to a Soap-Service gathering some data.
Part of this Data are Image URL's. I'm using a HttpWebRequest to download
and cache those images. (not many)

After a few (less then 10) (synchronous) SOAP-Calls I get the Error "There
were not enough free threads in the ThreadPool object to complete the
operation".

After some research in the net I'm quite sure I understand the "problem",
but how to workaround this? I already checked with some debugmessages and
the applikation threadpool reports always 25/500 free threads/iothreads.

So main questions are:
a) Is there any alternativ soapclient-class around which I can use, which
will not use the default threadpool, at least in synchronous calls?
b) Any "hack" to make it use a ManagedThreadPool?
c) What is the suggested workaround to make the cf httpwebrequest releasing
the resources to the pool to be able to reuse them.

Env: WinCE 6.0, ALL QFE , CF 2.0 , OpenNETCF SDF 2.1

Thanks in advance,

Ulrich
 
U

Ulrich Strauss

In case someone runs into the same Problem:

After digging around in the code and debugging ther reason was isolated.
The Problem occours because of heavy usage of Timers.
When analysing the threads being used we saw that almost all threads of the
ThreadPool are used by the Timer.ping which was caused by
a timer that had a very low tick-frequency. Together with
Soapcalls/webrequests and some background workers (sdf) this made overflow
the threadpool
pretty soonish.

counteractive measures:
a) Create a ManagedThreadPool which will queue up workitems when the
Threadpool is busy. (Basically porting of Stoub's ManagedThreadPool class to
cf)
b) make sdf-backgroundworker use the ManagedThreadPool
c) Replace all timers by Backgroundworkers
d) Extend sdf-backgroundworker to decide if Invoke is needed. (Because
Invoke again locks and will fillup the queue) This cost some time to find
out. we even managed to get Invoke to deadlock somehow :)
(in our special case Invoke is not necessary)

Afterall, our fault, but I think that the ThreadPool should queue up if it's
busy. HttpWebRequest throwing a imho wrong expection (It's neither a Connect
failure nor outofmemory) is really confusing in synchronous mode.

-Ulrich
 
Top