[omniORB] omniNames performance issues on Solaris 2.8.....

[Duncan Grisby]

On Wednesday 20 November, steinhoffc@schneider.com wrote:

>      We then started to look at our code and the omniNames installation.
> Rational Quantify has shown that the block of code is completely dominated
> by the list(), next_n() and destroy() methods to omniNames.It also
> indicated that the iterator returned from the list() method was not nil,
> but always returned an empty list from the next_n() call, and was then
> destroyed.  This raised the question as to why a non-nil iterator was
> returned in the first place.. This cause as to make the following code
> change in the ./omniORB-4.0.0/src/appl/omniNames/NamingContext_i.cc.

I have checked in Kendall's addition to omniNames. Thanks for that.
Nobody has ever considered the old behaviour a problem before,
presumably because people don't generally require huge performance
from the Naming service.

>      We then looked at the ORB and saw that it was doing a lot of
> LOCATE requests to the name service.

Was this with the original version, or the modified one that returned
nil iterators?  With the original, each new iterator would cause a
locate request to check that it really existed.

>  By going back to the
> resolve_initial_references() call each time a lookup is going to
> happen, it may be causing omniORB to 'forget' what it knows about
> the name service's object reference.

In some cases, resolving the root naming context again would cause a
new object reference to be created, and thus trigger a new locate
request. If you can store the object reference yourself, that will
guarantee the locate request doesn't happen again. How are you
configuring the naming service location?  If you are using the old
ORBInitialHost/Port config, that will trigger a request to the service
on every resolve_initial_references call, in addition to the locate
request caused by the new object reference.

How many object references are you storing in the Naming service?
omniNames isn't designed to be particularly efficient, since it's
expected to be used purely to bootstrap applications, rather than
being under heavy load.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --