Interoperability with Orbix MT 2.3
Eoin Carroll
ewc@orl.co.uk
Fri, 23 Jan 1998 16:47:40 +0000 (GMT)
Note to users using omniORB2 and Orbix 2.3
A bug that was in Orbix 2.1 that affected interoperability has
re-appeared in Orbix 2.3MT on Solaris (the bug had been fixed in Orbix 2.2).
See http://www.orl.co.uk/omniORB/archives/1997-Oct/0030.html for a message
about the bug in Orbix 2.1 . This bug appears when an Orbix program attempts
to narrow an omniORB (or other non-Orbix) IOR for an interface defined inside
a module.
The CORBA 2 specification says that identifiers in a Repository ID should
be seperated by '/' characters (section 6.6.1, CORBA v2 Spec). Orbix 2.3
generates IORs containing the correct Repository ID, but, when narrowing
IORs it receives, it expects the identifiers to be seperated by '_'
characters.
This bug only shows up when interoperating with other ORBs, as Orbix first
checks the IOR's object key for the Repository ID information. If the IOR is
generated by Orbix, the object key will contain a Repository ID seperated by
'_' fields, and so it won't fall back to checking the Repository ID
associated with the IOR (which will be seperated by '/' characters).
When an IOR supplied by another ORB is narrowed, it doesn't recognise the
object key, and so falls back to checking the Repository ID associated with
the IOR. It fails to recognise it, (due to the '/' characters), and
tries to contact the orbixd on the host where the target object resides.
If there is no orbixd on that host, it will eventually fail. If there is,
it will invoke the "getIIOPDetails" operation on the orbixd (it is possibly
trying to get the orbixd to return type information about the object, or
getting it to launch an Interface Repository to find this information), and
will then hang.
The same workaround as for 2.1 ( see
http://www.orl.co.uk/omniORB/archives/1997-Oct/0030.html ) will not work
(other than in some limited circumstances).
--
Eoin Carroll ewc@orl.co.uk
Research Engineer
Olivetti & Oracle Research Lab
Cambridge, UK