Take the 2-minute tour ×

There is a lot on multithreading on the Corba server side, but I'm interested about the client side. We have a multithreaded client (Solaris, Orbix 6.3) with a Corba singleton "manager" that initialises the ORB. During runtime 'lsof' shows only one TCP connection to the Corba server, so all synchronous calls made from the client worker threads should be serialised.

Would like to change this arrangement to take advantage of parallelism: each thread to manage its own connection. I've changed the setup so that instead of a singleton each worker thread calls ORB_init(), etc.

Totally puzzled now: 'lsof' shows now 2 TCP connections but there are 6 worker threads. Something is not right, would have expected as many TCP connections as the number of worker threads. May be that the approach is naive - does it makes sense for example to call ORB_init() per thread?

I'd need someones opinion on this. Sample code for a multithreaded client would greatly help. Again, using Orbix 6.3 on Solaris.

Kind regards,


share|improve this question
I see you've done something similar, to what I'm trying to do. Here's my question - stackoverflow.com/questions/13009694/… . Do you have any ideas? (+1 for your question - internet is really poor for information about multithreaded CORBA clients and damn rich for multithreaded CORBA servers). Thanks in advance! –  Kiril Kirov Oct 22 '12 at 10:49

5 Answers 5

The management of connections is implementation specific for plain CORBA. Each vendor has its own proprietary way of configuration their behavior. If you check the RTCORBA specification, that has a standardized way to configure how connections between client and server will be used.

I don't know how Orbix works and whether it supports RTCORBA, that is something you could get from their manuals probably. I do know that TAO has a lot of support for threading at the client side. By default when multiple threads make an invocation to the same server multiple tcpip transports can be opened at the same moment.

share|improve this answer

Orbix internally uses a lot of optimization routines to ensure that connections are used efficiently. Specifically, it's not going to open up multiple connections to the same server endpoint because it's able to multiplex multiple concurrent GIOP requests over the same TCP connection. CORBA deliberately hides connection management from client and server programmers.

I don't believe this is controllable through configuration. Send a support ticket to Progress Support to confirm. You might be able to force it to happen if you move away from the singleton model and initialize a different ORB for each client (each with their own unique ID), but that would be a very heavy-handed and costly solution to a problem that is a little vague. The underlying ORB is already build to optimize for concurrent requests, so I'm not sure what problem it is you're trying to solve.

share|improve this answer
Thank you Brian. What you say makes sense. I had the impression that calls are serialised one after another. This may not be the case, they may indeed be interleaved, i.e. multiple requests pushed down the wire from different worker threads, followed by multiple replies dispatched to those threads. There is indeed a more intelligent handling. –  Adrian Rosoga Oct 7 '12 at 16:02

In my honest opinion I don't think there is such a concept called multi threaded client for CORBA applications. Because in the server side, there is only one object that is registered with the naming service which is available for all the clients. If you look at the IOR of the object, it will be same for all the clients. So it can establishes at most only one connection to that object. It also leads to thinking that you can not get more than one remote object (which means how much ever you do look-up for the object from different clients, they all get the same reference) for any number of clients. So, in order to support mutli-threading ,the server actually has to support different thread policies. POA the server can have different thread policies. Please go through JAVA PROGRAMMING WITH CORBA for more.

share|improve this answer
What is about implementation repositories and dynamic interfaces? –  tuergeist Sep 25 '12 at 7:43
Even with one object on the server, the ORB could create multiple tcpip connections. There are also other ways to get/create object references, you can easily provide multiple objects from the server to multiple clients. Also check the various POA policies like servant locators that could deliver a servant per client. –  Johnny Willemsen Sep 25 '12 at 8:23

I don't know how exactly Orbix works, but normally ORB initialization in done only once even for a multithreaded setup. The multithreaded (server side) ORB will start an amount of worker threads (on demand or if needed or if configured, a fixed number) to handle incomming connection. These connections are handled by a worker. This worker looks up the servant that can handle this request. Normally this (the real call to the servant) is performed in an extra thread also. But you won't see this thread with lsof. Try so use ps -eLf or top -H with thread support enabled.


On the client side it depends on how many object do you want to call. For each object a caller thread is possible. It is also possible to have more than one caller thread per remote object, but only if called from different threads on the client side logic. (Imagine to have multiple threads and the remote object is shared across the threads)

share|improve this answer
Thank you. As said though, I was looking at the client side - outgoing connections. –  Adrian Rosoga Sep 24 '12 at 13:10
Got from omniorb.sourceforge.net/omni41/omniORB/omniORB008.html: 8.3 Client side behaviour On the client side of a connection, the thread that invokes on a proxy object drives the GIOP protocol directly and blocks on the connection to receive the reply. The first time the client makes a call to a particular address space, the ORB opens a suitable connection to the remote address space (based on the client transport rule as described in section 8.7.1). After the reply has been received, the ORB caches the open network connection, ready for use by another call. This may explain. –  Adrian Rosoga Sep 24 '12 at 13:12
Sorry, had to reply using multiple comments. So, the only chance may be to find out the Orbix config parameter (if any) that disables this caching of the outgoing network connection. –  Adrian Rosoga Sep 24 '12 at 13:17
What you mean is connection re-use, this is common and improves performance as establishing a connection takes time. –  tuergeist Sep 25 '12 at 7:45

Thank you guys for your answers. I found, as Johnny says that this is indeed implementation specific.

omniORB has for example maxGIOPConnectionPerServer - default 5. That's: The maximum number of concurrent connections the ORB will open to a single server. If multiple threads on the client call the same server, the ORB opens additional connections to the server, up to the maximum specified by this parameter. If the maximum is reached, threads are blocked until a connection becomes free for them to use.

Unfortunately I haven't yet found out what's the equivalent (if any) for Orbix. It's definitely defaulting to 1 connection. Still googling...

Found out though that as part of Solaris -> Linux migration will be moving from Orbix to TAO in a number of months. Hoping TAO would be more friendly and customizable.

share|improve this answer

Your Answer


