[rabbitmq-discuss] .NET Client ConnectionFactory threading issues

[Chris Haines]

Hi All,

This had nothing to do with the actual ConnectionFactory. This was because 
our application was thread starved.

The .NET ThreadPool by default has a small number of threads available. The 
minimum number of available threads was set to 8. This means that once 8 
threads have been requested (and still being used) then the ThreadPool 
switches over to an algorithm to decide whether to create new threads in 
the pool or wait for a thread to become available. This algorithm is not 
very generous at creating new threads, so what we were seeing is that the 
connections were timing out on creation due to waiting for a thread to 
become available, not problems within the RabbitMQ client libraries.

You can get round this by setting the minimum number of threads available 
in the ThreadPool, which means that the number specified get created on 
your application start up:

ThreadPool.SetMinThreads(minWorkerThreads, minCompletionPortThreads);

Cheers,
Chris

On Thursday, 18 April 2013 12:37:40 UTC+1, Chris Haines wrote:
>
> Hi All,
>
> I have attached a .cs Nunit test fixture to demonstrate a problem I am 
> having with the ConnectionFactory. If I create 100 connections in a for 
> loop single threaded then I can create them all in about 2 seconds. If I 
> create them via a number of threads, in my test I am using 100 threads to 
> create a connection on each, then I get a lot of timeout exceptions (my 
> test bails out after 60 seconds). I have tried sharing an instance of the 
> ConnectionFactory between all threads and also giving each thread its own 
> instance but they both have the same result. I have also tried locking 
> around the call to CreateConnection but that also didn't help. 
>
> I find this behavior to be very strange. Has anyone else had similar 
> problems?
>
> Cheers,
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130501/9a0f033b/attachment.htm>