[omniORB] unbind after orb->run fails
Olaf Meding
olaf@tomotherapy.com
Thu, 26 Apr 2001 08:51:47 -0500
Duncan,
> initializing ORB
> bind with the name service
> create servant
> orb->run()
> unbind name from name service // COMM_FAILURE here
> ... the code sequence you are trying is illegal ...
So how do I legally unbind the name form the name service?
Maybe, call unbind() before calling orb->shutdown()? But the
orb->shutdown() is called from a different thread. It was my understanding
that orb->shutdown() is the only orb call that can be called from a
different thread.
Or maybe, do an ORB_init() right after orb->run() returns? But wouldn't
that cause potential race conditions?
Any other ideas?
Olaf
-----Original Message-----
From: owner-omniorb-list@uk.research.att.com
[mailto:owner-omniorb-list@uk.research.att.com]On Behalf Of Duncan
Grisby
Sent: Thursday, April 26, 2001 6:08 AM
To: Olaf Meding
Cc: omniORB Mailing List
Subject: Re: [omniORB] unbind after orb->run fails
On Wednesday 25 April, "Olaf Meding" wrote:
> initializing ORB
> bind with the name service
> create servant
> orb->run()
> unbind name from name service // COMM_FAILURE here
I don't know why you are getting a COMM_FAILURE. Can you run your
program with command line arguments -ORBtraceLevel 10
-ORBtraceInvocations. That will print some debugging information,
including where the COMM_FAILURE came from.
That said, the code sequence you are trying is illegal according to
the CORBA specification. Section 4.2.3.4 of the 2.4.2 specification
says:
"Once an ORB has shutdown, only object reference management
operations (duplicate, release and is_nil) may be invoked on the
ORB or any object reference obtained from it. An application may
also invoke the destroy operation on the ORB itself. Invoking any
other operation will raise the BAD_INV_ORDER system exception with
the OMG minor code 4."
omniORB 3 does usually permit object reference operations after the
ORB has shutdown, which is why I'm surprised by your COMM_FAILURE.
omniORB 4 will properly raise an exception in this case.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --