Page History

...

1. Manual activation/deactivation of the CORBA object
2. Manual activation with automatic deactivation of the CORBA object through the POA cleanup process
3. Manual activation/deactivation of the CORBA object through the container services

The first two are very similar to the Standalone Client, but with some caveats that will be explained in the following sections

Manual OffShoot activation/deactivation

The implementation is exactly the same as in the standalone client, the restriction here is just a bit stricter, here we need to deactivate the OffShoot servant before the component is deactivated. It could be part of the method, or be implemented as part of the cleanUp/aboutToAbort component's lifecycle methods, depending on the design decisions. If due to your design it fails to deactivate the OffShoot servant before deactivating the component, then you will get undefined behavior and probably segmentation fault when shutting down the container.

Another downside from this approach is that the ACS developers need to interact directly with CORBA details.

Manual OffShoot activation with automatic deactivation

While technically feasible, there are additional complications to implementing this both for stack and heap OffShoot servant instances. The component is always deactivated before the ORB shuts down, implying that the stack variables will get deleted before the ORB shuts down, resulting in undefined behavior and usually segmentation fault when container is shutting down. It should be possible (although not recommended) to workaround this by storing the servant in global or class variables. For the heap variables, it is possible to skip the deletion of the variable and delegate that to the POA cleanup process.

Both cases have other complications due to dynamic library loading of shared objects. Since in both cases the actual destruction of the OffShoot servant objects has been delayed until after the dynamic libraries have been unloaded, the memory address (pointer) is not associated to any known definition. Trying to delete these objects has undefined behavior and usually leads to segmentation fault.

Both cases have a base workaround, by starting the container with some dynamic libraries pre-loaded:

LD_PRELOAD=$INTROOT/lib/libAsyncClientImpl.so acsStartContainer -cpp bilboContainer

But while this works, it beats the whole purpose of dynamic deployment through the CDB. If we want to redeploy the components, we would need to change the container starting scripts to make sure we pre-load appropriate libraries.

In the case of the heap OffShoot servant we are running in a memory leak scenario. To prevent the leak, we need to guarantee the POA handles the destruction of the OffShoot servant instance. We can do that by removing one reference from the counter, so when the POA reduces the counter by one, it forces the destruction of the variable:

MyCBImpl* cb = new MyCBImpl(); //Ref count = 1
examples::MyCallback_var cbObj = cb->_this(); // Ref count = 2
cb->_remove_ref(); // Ref count = 1
...
// When the ORB stops, the counter is reduced once more
// Leading to Ref count = 0 and triggering
// delete this; //Same as delete cb;

Do not reduce the reference count when using stack OffShoot servant instance as it will trigger double free unexpected behavior (and probably segmentation fault).

Manual Offshoot activation/deactivation using ACS container services