[omniORB] Problem with multithreading policy?

[David Riddoch]

Hi Viktor,


This has been discussed on the list before, and is fixed in omniORB 3pre-x
(and there is a kludge for 2.8).  See the previous thread at:

  http://www.uk.research.att.com/omniORB/archives/2000-01/index.html#119


Cheers,
David




On Thu, 29 Jun 2000, Viktor Mikho wrote:

> It seems that there is a problem with the way how omniORB selects threads on 
> the server side to perform a request. I have a test program that fires 
> requests to the omniOrb 2.8.0 server on NT from several threads. On the 
> server side actions on receiving request is as follows:
> 
> - log incoming time and thread
> - wait for random interval (500-5000 msc)
> - log outcoming time and thread
> 
> In my case I use the default value of 5 omniORB::maxTcpConnectionPerServer 
> threads.
> The problem I see is that you are stupid enough to have more than 5 threads 
> (even in the bursts) sending messages then performance is actually 
> equivalent to ONE THREAD.
> It is because omniORB uses the same thread again and again when busy. In the 
> following log you can see that starting from the request 5 all execution 
> happens in the thread 167 while other 4 threads are not busy.
> So, performance in fact is one-threaded.
> Is it a problem or I am doimg something wrong?