[omniORB] Please clarify behaviour of omniOrbPOA::deactivate_object (poa.cc - 1261)

[Martin B.]

Greetings!

I am slightly confused by the behaviour vs. the comment provided with
the deactivate_object() function of omniORB.
The comment in poa.cc looks like this:

- - - - omniORB 4.1.2 / poa.cc, line 1260 - - - -
void
omniOrbPOA::deactivate_object(const PortableServer::ObjectId& oid)
{
// Once an object is targeted for deactivation, things happen in
// this order:
//
// o wait for requests to complete
// -- note that new requests can arrive in the mean time, so the
// deactivation may never actually complete! This is
// necessary to prevent deadlocks in objects which do
// re-entrant calls to themselves.
// o remove from active object map
// o etherealise
//
// It is not possible to reactivate the same object until the
// etherealisation stage has happened. Attempts to do so are blocked
// until it is safe to continue.
- - - -

The "note" confuses me, because from what I can see in the code,
deactivate_object() will always and unconditionally call
...
entry->setDeactivating();
entry->removeFromOAObjList();
...
and then handle the waiting for outstanding requests separately.

This is also what I observe in my tests, namely that after I have called
deactivate_object(), all new requests via any already existing object
references will throw CORBA::OBJ_ADAPTER ( OBJ_ADAPTER_POAUnknownAdapter ).

Is this comment plain wrong, or do I misunderstand something about this?

cheers,
Martin

[Duncan Grisby]

Post by Martin B.
I am slightly confused by the behaviour vs. the comment provided with
the deactivate_object() function of omniORB.
- - - - omniORB 4.1.2 / poa.cc, line 1260 - - - -
void
omniOrbPOA::deactivate_object(const PortableServer::ObjectId& oid)
{
// Once an object is targeted for deactivation, things happen in
//
// o wait for requests to complete
// -- note that new requests can arrive in the mean time, so the
// deactivation may never actually complete! This is
// necessary to prevent deadlocks in objects which do
// re-entrant calls to themselves.
// o remove from active object map
// o etherealise
//
// It is not possible to reactivate the same object until the
// etherealisation stage has happened. Attempts to do so are blocked
// until it is safe to continue.
- - - -
The "note" confuses me, because from what I can see in the code,
deactivate_object() will always and unconditionally call
...
entry->setDeactivating();
entry->removeFromOAObjList();
...

The comment is correct. Those calls to setDeactivating() and
removeFromOAObjList() do not prevent further requests coming in to the
object. They are merely the first stage of deactivation. It is not until
setEtheralising() is called in lastInvocationHasCompleted() that new
incoming requests are denied.

Post by Martin B.
and then handle the waiting for outstanding requests separately.
This is also what I observe in my tests, namely that after I have called
deactivate_object(), all new requests via any already existing object
references will throw CORBA::OBJ_ADAPTER ( OBJ_ADAPTER_POAUnknownAdapter ).

That exception will only be thrown if the object adapter itself is
destroyed, not if an object is deactivated. Once an object is completely
deactivated, calls will throw CORBA::OBJECT_NOT_EXIST, not OBJ_ADAPTER.

Cheers,

Duncan.

[Martin B.]

Post by Duncan Grisby

Post by Martin B.
I am slightly confused by the behaviour vs. the comment provided with
the deactivate_object() function of omniORB.
- - - - omniORB 4.1.2 / poa.cc, line 1260 - - - -
omniOrbPOA::deactivate_object(const PortableServer::ObjectId& oid)
// Once an object is targeted for deactivation, things happen in
//
// o wait for requests to complete
// -- note that new requests can arrive in the mean time, so the
// deactivation may never actually complete! This is
// necessary to prevent deadlocks in objects which do
// re-entrant calls to themselves.
- - - -
The "note" confuses me, because from what I can see in the code,
...

The comment is correct. Those calls to setDeactivating() and
removeFromOAObjList() do not prevent further requests coming in to the
object. They are merely the first stage of deactivation. It is not until
setEtheralising() is called in lastInvocationHasCompleted() that new
incoming requests are denied.

Thanks!

Post by Duncan Grisby

Post by Martin B.
and then handle the waiting for outstanding requests separately.
This is also what I observe in my tests, namely that after I have called
deactivate_object(), all new requests via any already existing object
references will throw CORBA::OBJ_ADAPTER ( OBJ_ADAPTER_POAUnknownAdapter ).

That exception will only be thrown if the object adapter itself is
destroyed, not if an object is deactivated. Once an object is completely
deactivated, calls will throw CORBA::OBJECT_NOT_EXIST, not OBJ_ADAPTER.

Oh! I guess this means sloppy testing on my part. Since I only
deactivated the object at app shutdown, I may have intermingled the
effects of object deactivation and POA deactivation. Thanks for the
clarification!

cheers,
Martin