[omniORB] local invocations

[Duncan Grisby]

On Saturday 10 November, Stephen Davies wrote:

> First off omniNames triggers assertion faults whenever a client tries to
> use it: eg3_impl, nameclt list and the berlin server all cause this.
>  file: callHandle.cc
>  line: 127
>  info: pd_localId
> Cannot resolve the root context.
> Have you set up the configuration file properly?

This is a bug in the way the bootstrap agent is implemented. It's on
the list of things to fix. However, you shouldn't be using the
obsolete and proprietary boostrap agent unless you need to talk to the
JavaIDL name service. Use a corbaname or corbaloc URI instead. Put
something like

  InitRef = NameService=corbaname::myhostname

in your omniORB.cfg.

> There is an error in the sample.cfg file: bootstrapAgentHostname should
> not have quotes, as it does name lookups verbatim, including quotes, which
> obviously fails (and caused me no end of headaches...)

Thanks for pointing that out. As I say above, you shouldn't be using
it, though.

> The berlin C++ demo client causes another assertion fault:
>  file: ../omniInternal.cc
>  line: 634
>  info: pof
> Segmentation fault

Something is confused. That error has come from omniORB 3. I suspect
you've somehow managed to link against both omniORB 3 and omniORB 4.

> The berlin server works fine (now that I have the nameService stuff
> working), until I try using the shortcut poa. If I do, I get a lockup
> waiting for a mutex. I'm not sure if I did it correctly, but I took the
> code from the wiki and used the new shortcut_poa everywhere the rootpoa
> was used previously, ignoring all issues with threading etc..

You haven't activated the shortcut POA, so it's in the holding state.

> I noticed that not all objects were created in root/shortcut (I looked at
> one and it calls _this() in the constructor, which I guess uses the root
> poa). This is the first call into an object in the root/shortcut poa.

When _this() does an implicit activation, it does it in the Root POA,
unless you implement a _default_POA() function in your servant that
returns a different POA. New POAs you create do not, by default, have
the implicit activation policy, so you'll have to add that policy to
the shortcut POA if you need implicit activation.

Cheers,

Duncan.

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