Question

I use ORBacus. I have a multithreading application and I want to have several ORB objects in the same process. The idea is: each thread to have its own ORB and to be connected to different server.

Is this even possible? If so – how?

---

“What have you tried?” : I have

CORBA::ORB_var m_varOrb;

in each thread. Each thread calls. Each thread has Reconnect method, which executes:

// ...
m_varOrb = CORBA::ORB_init( argc, argv );

The issues, I have:

• when several threads are trying to reconnect at the same time, the application crashes in m_varOrb->destroy(); or in CORBA::ORB_init.

• I tried to sync the threads, so that all threads try to reconnect to the configured server one by one (using a static mutex) – still not working – when one thread tries to destroy “its” ORB object – crash again in destroy (some assert fails, because some reference count is > 1; looks like a reference counting pointer to the real ORB object)

• I added a conditional wait, so the threads start calling ORB_init only when all threads has executed destroy; made a singleton wrapper class around the ORB, sync-ed the threads to connect one after the other and everything started working perfectly fine. BUT this means – only one ORB, so only one server. Bad.

So, all of these things made me thing, that I’m allowed to have only one ORB object per process. Am I missing something?

Answer 1

By default, CORBA ORBs should behave like singletons if you pass the same “ORB id” parameter when initiatlizing them with ORB_init(). However, you’re probably passing the same parameter each time, which means that the ORB assumes you want all those threads to share the same underlying ORB instance.

So the first thing you need to do is to find in ORBacus’s documentation how to pass unique ORB IDs within each thread. Perhaps use the thread ID as the discriminant.

That said, your approach could use improvement. Creating an ORB in each thread is a very expensive operation. Instead, create one shared ORB on application start and then allow each thread access to it. It should be already protected by ORBacus against concurrent access. Make sure you only do ORB shutdown/destroy in the mainline too, not in the threads.