[omniORB] Problem with multi-threading omniORB/ORBacus for Java!?

[randy.shoup@tumbleweed.com]

How coincidental.  We experienced exactly this same issue recently with
an Orbacus client and an omniORB server.  

The quick explanation is that this is the result of a mismatch in
connection/threading policies between Orbacus and omniORB:

Orbacus by default shares a single connection between multiple threads. 
The multiple threads are multiplexed over the single connection.  You
get concurrency by adding more threads using the same connection on
client ("threaded") and server ("thread_per_request" or "thread_pool").

omniORB's model is thread-per-connection, so a given connection to the
server will only be serviced by a single thread.  You get concurrency by
having multiple *connections*, each serviced by a single thread on the
server side.

The only easy way to work around this inconsistency is to use the
ConnectionReusePolicy setting in Orbacus to encourage the client to use
multiple connections.  See the manual.  See also my thread of argument
with the Orbacus folks that they really ought to support a connection
pool on the client side a la omniORB :-) :

http://www.ooc.com/pipermail/ob-users/2001-March/016757.html

The other route to go, of course, would be to rework (or make
configurable) the connection/thread model in omniORB.  I happen to be
convinced by the advantages of the omniORB model as described in the
paper on the website, but the fact is that most other ORBs do it the
thread-pool way, as I understand it: TAO, Orbix, Orbacus, etc.

Peter-Rene Steiner wrote:
> 
> Hello all,
> 
> I got a problem concerning multi-threading awareness of
> omniORB and ORBacus (using omniORB 3.0.2, JOB 4.0.5,
> Windows NT 4.0 SP6a, MSVC6++/SP3).
> 
> The details:
> 
> Let us a have a simple interface like the echo example: here the server
> has only one method that prints a text, sleeps for 5 seconds, then returns.
> The client creates a number of threads (say 20) all calling this one method
> nearly at the same time.
> 
> 1. Using omniORB for client and server. [C++/C++]
> I have set "omniORB::maxTcpConnectionPerServer = 15;" in server and client sources.
> Everything works as expected: 15 calls are accepted, 5 seconds delay,
> for each returning call another waiting thread comes in; so there are 5
> calls waiting in a second phase, finally after a total of 10 seconds everything is done.
> Great.
> 
> 2. Using ORBacus for Java for the client. [J/C++]
> Server executable unchanged, still omniORB.
> I have set
>    props.put("ooc.orb.conc_model", "threaded");
>    props.put("ooc.orb.oa.conc_model", "thread_per_request");
> in the Java code as documented by OOC. Now 20 threads are starting and calling,
> but each 5 seconds one call returns, another comes in, after a total of 100 seconds
> the job is done. The calls seem to be serialized.
> Not great.
> 
> 3. Using same JOB client with a server created with JOB.   [J/J]
> Works as expected.
> 
> 4. Using the omniORB client from (1.) with that JOB server from (3.) [C++/J]
> Works as expected.
> 
> Any ideas?  Maybe I can post the sources, but some first thoughts would be fine!
> 
> Greetings,
> Peter-Rene Steiner

-- 

-- Randy
_________________________________________________________________  
Randy Shoup                                     (650)216-2038  
Senior Architect                                rshoup@tumbleweed.com  
Tumbleweed Communications Corporation