[omniORB] omniORBpy/AdapterActivator/find_POA problem

[Duncan Grisby]

On Thursday 2 August, Patrick Hubert wrote:

> I'm having a bit of a problem with omniORBpy while trying to use an
> adaptor activator...
> 
> In a nutshell:
>  - if I activate the RootPOA's POAManager before doing my
>    find_POA (thus calling unknown_adapter in my activator), it
>    works, but when the application exits I get:
> 
>    omniORB: Application check failed. This indicates a bug in the application
>    using omniORB.  See the comment in the source code for more info.
>    file: ../poa.cc
>    line: <varies: 1281 for 3.03 and 1344 for 3.04>
>    info: pd_destroyed == 2

This is a bug in the ORB core. find_POA() would fail to increment the
POA's reference count when using the AdapterActivator. I suspect
anyone using find_POA() with AdapterActivators from C++ would just
assume they had got their reference counting wrong and add an extra
_duplicate() without really thinking about it. Since omniORBpy does
its counting right, it tripped over the bug.

It's fixed now in CVS.

>  - if I activate the manager after the call to find_POA, the call
>    to find_POA hangs without ever calling my activator. I have to
>    <ctrl-z> and kill my program... <ctrl-c> does not do anything.
> 
> According to Henning/Vinoski (p.514-520), the POAManager does not have to
> be activated for the adaptor activator to work...

Henning and Vinoski are wrong. The AdapterActivator is a CORBA object
which is registered in a POA. If the POA it is registered in (in your
case the RootPOA) is in the holding state, calls to the
AdapterActivator object should be blocked.

It is certainly possible to associate an AdapterActivator with a POA
in the holding state, and have unknown_adapter() called, _as long as
the AdapterActivator is activated in an active POA_. i.e., you can do
something like

  rootpoa = orb.resolve_initial_references("RootPOA")

  # Create a POA just for AdapterActivators. Note that the new POA has
  # its own POAManager.
  aapoa = rootpoa.create_POA("ActivatorPOA", None, [])

  # Create the AdapterActivator servant and activate it in its own POA
  activatorServant = LocalAdapterActivatorServant()
  aapoa.activate_object(activatorServant)
  activatorObject = activatorServant._this()
  rootpoa._set_the_activator(activatorObject)

  # Activate the AA POA so calls to unknown_adapter() are dispatched
  aapoa._get_the_POAManager().activate()

  # Cause the child to be activated. The RootPOA is still in the
  # holding state
  mypoa = rootpoa.find_POA("MyPOA", 1)


So you've found two bugs: one in omniORB, and one in H&V's book :-)

Cheers,

Duncan.

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