ThreadPool Running Out of Threads on SOAP Calls

Add-in Express™ Support Service
That's what is more important than anything else

ThreadPool Running Out of Threads on SOAP Calls
 
Tony Stephens




Posts: 22
 Joined: 2007-10-26

Hi Experts,

I've created an add-in that extends the Outlook appointment form and that communicates with an external service via a web service. I create a single soap proxy that is used from two threads. In my add-in I have a watchdog thread started within the appointment form that authenticates the end user and updates a traffic light on the form to show that the external service is available (polls the service every 30 seconds or so). I also use the soap proxy within the "main" Outlook thread (also invoked within the form when ProcessSend events occur) to invoke the web service to provision the external service platform.

I'm getting curious "There were not enough free threads in the ThreadPool to handle the request" exceptions periodically occuring within my watchdog thread. Has anyone else experienced this kind of problem before ? Even if I lock the proxy object to gaurentee only a single request at a time I still get this exception thrown. Are there any threading or ThreadPool caveats I should be aware of for add-ins within Outlook ?

I'm currently using .NET 1.1 (but will need to support later versions also) and I understand that even the synchronous calls are in fact asynchronous calls (looking at the generated proxy) and that for a large number of concurrent requests this would consume all the ThreadPool threads (I believe the default thread pool size is 25 per process). Is Outlook, the interop dll, or other add-in bits sharing this threadpool and possibly consuming these threads ?

Anyone know how to resolve this issue? Many of the posts on the msdn forums suggest modifying ASP.NET or other server side settings but this is a client side issue.


Thanks for your time,

Tony
Posted 08 Nov, 2007 06:02:02 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
 Joined: 2004-07-05
Hi Tony.

As far as I know each request to the web service creates its own instance of the web service class. The lifetime of the web service class should be limited and configured in the ASP.NET application. Probably the add-in exceeded the number of possible connections on the server side.
Posted 08 Nov, 2007 11:06:30 Top
Tony Stephens




Posts: 22
 Joined: 2007-10-26
Hi Sergey,

Using Spy++ I've been able to determine thread usage at various points while using Outlook with and without the add-in. With no add-in on start up Outlook uses about 30 threads and usage stays at this level when I create an appointment and delete it.

When I run Outlook with the add-in the number of threads starts at 35 and increases to 50 when I open and send an appointment. These additional threads never seem to be released.

In my code I'm creating 2 threads and the SOAP proxy I create will be using threads from the managed thread pool as well. There appears to be a "thread leak" occurring somewhere. My debug log is showing that the Dispose methods where I'm shutting down threads are being called, Dispose is being called on the soap proxy, and debug within the thread functions to show that these are exiting.

Either the garbage collector is very slow at reclaiming these threads or there are references to these additional threads within the managed code that are not being released.


Any ideas ?

Thanks,

Tony
Posted 09 Nov, 2007 11:39:29 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
 Joined: 2004-07-05
Tony, you can force GC to collect released objects.

GC.Collect();
GC.WaitForPendingFinalizers();
Posted 09 Nov, 2007 17:59:42 Top
Owen Rogers




Posts: 30
 Joined: 2007-11-01
we're running into a similar problem on some clients. we're seeing the Outlook process occasionally consuming 120+ threads. from running the addin in a profiler, it seems like the WatchEngine is generating a lot of threads. from looking at the source, at least the version of the source that I have locally, the WatchEngine starts a system timer to run every 10 ms (should this be configurable?). one possibility is that as the performance of the machine starts to degrade under load, the timer execute methods start to pile up, eventually consuming all of the threads in the pool. maybe the WatchEngine should stop the Timer for the duration of the command that it is executing?
this may have been resolved in a more recent version of the library.
Posted 12 Nov, 2007 03:28:09 Top
Tony Stephens




Posts: 22
 Joined: 2007-10-26
Hi Sergey,


I believe I've isolated the problem to the soap proxy. I have a small test application that creates, invokes, and disposes the soap proxy. The thread usage increases to 10 when a web service method is invoked and proxy.Dispose() doesn't release them. However, if I recreate the proxy and go through the same test cycle again the number of threads consumed stays constant. Maybe the .NET framework/process is hanging on to the additional threads for some performance reason (?). I've also tried invoking the garbage collector as you suggested but this doesn't release any of the additional threads.

Between Outlook and the add-in these seem to be consuming all the available managed threads in the process thread pool causing the exception I'm seeing. I'm developing/debugging the add-in using Outlook 2003 running on Windows 2000 SP2 with .NET 1.1. No doubt if I move to a different combination of Outlook, Windows, and .NET I'll get different (proxy) behaviour.

Anybody else seen similar threading issues while developing an add-in ? Looks like I'll have to look for the proverbial needle on Microsoft's MSDN site.


Thanks,

Tony
Posted 12 Nov, 2007 11:04:19 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
 Joined: 2004-07-05
Hi Tony.

Please try to ask this question in Microsoft news groups. Let me know if Microsoft's guys answer you.
Posted 12 Nov, 2007 12:31:19 Top
Tony Stephens




Posts: 22
 Joined: 2007-10-26

Hi Sergey,

I've posted a couple of messages on Microsoft's MSDN forum and have yet to receive a response. As a matter of interest does the add-in framework code itelf make use of the managed thread pool ? I'm wondering what is consuming all 25 thread pool threads.

My only option at the moment seems to be to use a SOAP proxy implementation that isn't dependent upon the managed thread pool (one of my questions on the MSDN forum) and with no response there, this currently suggests I'd need to write one :(


Thanks,

Tony
Posted 20 Nov, 2007 12:56:52 Top
Sergey Grischenko


Add-in Express team


Posts: 7233
 Joined: 2004-07-05
Hi Tony.

Add-in Express doesn't run any threads.
If the add-in is loaded by MS Access, Add-in Express uses the timer to add command bars and controls.
Posted 21 Nov, 2007 08:35:29 Top