[omniORB] thread pool vs. thread per connection

[Rainer Frohnhoefer]

Am Montag, 25.11.02 um 19:49 Uhr schrieb baileyk@schneider.com:

[snip]
> Is anyone else depending on the thread pool policy added to omniORB4, 
> and
> seeing excessive thread creation?  If my analysis is correct, is there
> interest in an "idle" thread pool policy to reduce the number of 
> threads
> created and destroyed?

  We're having the same Java->C++ problem, but we're not yet ready to 
switch our (big) server application to omniORB4 :(   ... currently 
we're using a couple of workarounds.

> My concern stems from this scenario:  a J2EE client tier ( servlet/JSP 
> )
> hitting a C++ omniORB server.  The Java ORB multiplexes calls over a 
> small
> number (possible one?) connection, but we need highest performance
> possible.  Some requests should take only 5-10ms while others may take
> several seconds.   Number of concurrent requests could be large (10 - 
> 15?).
> Thread creation/destruction overhead is not acceptable.  I suspect this
> isn't a unique role for omniORB to want to play in.

  Java ORBs which multiplex over one connection: JacORB, OpenORB, I 
think the Sun JavaIDL ORBs up to 1.4 as well.

  Don't know about the newer ORBs from Inprise and Iona.

  The one ORB that can definitely handle connection pools on the client 
side is ORBacus; it doesn't come cheap, unfortunately.

   So I couldn't really help much .....


  Regards,
	-Rainer.