[omniORB] Problem with multi-threading ...

[Peter-Rene Steiner]

Randy,

thank you very much for the detailed information. That was exactly the point.
Nevertheless, my next steps after reading your post were not successful -
I still had serialized behavior on the server. Now, after some in-deep discussions 
with OOC people, the problem seems to be solved finally.

The details:

In my Java client I created only one proxy object 

     org.omg.CORBA.Object obj = orb.string_to_object( ... );

     // Choose CONNECTION_REUSE_POLICY = false
     org.omg.CORBA.Any boolAny = orb.create_any();
     boolAny.insert_boolean(false);
     org.omg.CORBA.Policy[] policies = new org.omg.CORBA.Policy[1];
     policies[0] =
          orb.create_policy(com.ooc.OB.CONNECTION_REUSE_POLICY_ID.value, boolAny);

     // Override policy                
     org.omg.CORBA.Object newObj = 
          obj._set_policy_override(policies, org.omg.CORBA.SetOverrideType.ADD_OVERRIDE);
     System.out.println("new object created.");

     Echo e = EchoHelper.narrow(newObj);

then created the 20 threads, giving them 'e', and all threads called 

     e.echoString("some text");

With this construction changing the policy (on ORB _and_ object level) did not help. 

The point is: To have 20 connections in flight each thread must derive 
its own object either using  set_policy_override() (changing the policy on object
level) or orb.string_to_object() (with the policy already changed on ORB level).
This works now and as far as I understand there is no way to have one object 
with 20 calls in-flight concurrently with ORBacus.

If one doesn't change CONNECTION_REUSE_POLICY at all even these 20 objects will 
use the same connection, serializing on the omniORB server.

Now this seems to be a topic rather for the ORBacus mailing list than for
the omniORB area but I thought it could be useful to share my results.

Thank you again and best regards,
Peter-Rene Steiner



----- Original Message ----- 
From: <randy.shoup@tumbleweed.com>
To: Peter-Rene Steiner <peter-rene.steiner@bruker.de>
Cc: <omniorb-list@uk.research.att.com>
Sent: Tuesday, March 27, 2001 7:22 PM
Subject: Re: [omniORB] Problem with multi-threading omniORB/ORBacus forJava!?


> 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
>