[omniORB] omniNames and Java

Duncan Grisby dgrisby@uk.research.att.com
Wed, 10 Jan 2001 14:57:01 +0000


On Wednesday 10 January, "Robert Smith" wrote:

> When omniNames 3.0.2 is used the resolve_initial_references method in Java
> fails with an ArrayIndexOutOfBoundsException. This is due to a well known
> bug in the jdk1.3 ORB. However, omniNames 2.8.0 works fine with jdk 1.3.
> 
> Why is this - how does omniNames 3.02 differ from 2.80? Is it perhaps due to
> the INS support in 3.02? Does the bug only affect the nameservice or can it
> cause problems if talking to other C++ code which uses omniORB?

The problem is with the object key, which is used to identify an
object within an address space. omniORB 2.x always uses object keys
which are 12 bytes in length. The JDK ORB is happy with that.
omniORB 3's object keys vary in length depending on the name and
policies of the POA in use.

It seems to be the case that the JDK ORB has a bug for object keys
shorter than 12 bytes, but only if the object is on the same host as
the client. Unfortunately, the INS requires that the root context of
the naming service has the object key "NameService", which is only 11
bytes. Not only that, but sub-contexts of the root context have
objects keys of only 6 bytes.

In C++ code that you write, you just need to make sure that the object
keys for all your objects are longer than 12 bytes. omniORB generates
the object key as follows:

  ( <tag> POA name )* [ <tag> nonce ] <tag> object id.

Each tag is a single byte. The list of POA names represents the
hierarchy of POAs. Transient POAs include an 8 byte nonce, used to
keep the object keys unique for all time. System supplied object ids
are always 4 bytes; user supplied ones can be any length.

In the root POA, for example, the list of POA names is empty, so there
is just <tag> nonce <tag> system id, which is 1 + 8 + 1 + 4 = 14
bytes, so that's OK. However, a persistent POA named "foo" using the
system id policy would have <tag> "foo" <tag> system id = 1 + 3 + 1 +
4 = 9 bytes, which is too short for JavaIDL.

If you need persistent POAs, make sure they have names of 10
characters or more, and you'll be OK.

Please don't use this information to unpick omniORB's object keys. The
details may well change in future.


The Sun bug page for the problem is

  http://developer.java.sun.com/developer/bugParade/bugs/4351366.html

Unfortunately, they have closed the issue, claiming that it is not a
bug, despite the fact that it quite clearly is. Some of the comments
add more details about why it fails.


Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --