[omniORB] strange behavior of '_this()' method

[Michael]

Hi Michael,

Michael Kilburn wrote:
> Hi,
> 
> Recently I've (suddenly :-)) realized that our product never overrides
> _defaultPOA() method, but uses non-RootPOA for all objects (for
> MAN_THREAD_MODEL) and occasionally calls _this() method. After careful
> reading of CORBA standard I came to conclusion that _this() called for
> objects that are nor target of currently processed request should return
> reference acivated in RootPOA (thus wasting all our efforts to confine
> everything to our own POA). But it does not happen, it seems and after some
> digging I found why:
> 
> void*
> PortableServer::ServantBase::_do_this(const char* repoId)
> {
>     …
>   {
>     omni_tracedmutex_lock sync(*omni::internalLock);
>    if (_activations().size() == 1) {
>      // We only have a single activation -- return a reference to it.
>       omniObjTableEntry* entry = _activations()[0];
>       omniOrbPOA* poa = omniOrbPOA::_downcast(entry->adapter());
>       omniIORHints hints(poa ? poa->policy_list() : 0);
>       omniObjRef* ref = omni::createLocalObjRef(_mostDerivedRepoId(),
> repoId,
>                                                 entry, hints);
>       OMNIORB_ASSERT(ref);
>      return ref->_ptrToObjRef(repoId);
>     }
>   }
>   …
> }
> 
> Since our servants usually activated only in one POA and usually already
> activated before possible _this() call -- this code 'saves' us. But there
> are few cases when _this() might be called on non-active object -- and it
> behaves as I feared (i.e. gets activated in RootPOA).
> 
> Now questions:
> - I feel that this (probably helpful) behaviour is not standard-compliant --
> can someone prove that it is not the case?
Afaik this is in fact standard compliant.


> - is there any way to change RootPOA's policies? (to remove ecessity of
> creating another POA)
No (this is also defined in the standard)

> - I am trying to avoid necessity of overriding _defaultPOA (someone will
> forget to do it and it will lead to hard-to-find problems). So there any way
> to ensure that all objects get activated in specific POA without this?
You'll have to call activate on the correct poa explicitly (it shouldn't
be hard to verify this, assuming you have a reasonable code structure).
Maybe you should write a get_this helper template that makes sure
everything is activated the way you want it?!?

> - maybe it is possible to 'disable' RootPOA somehow?
I don't think so + I don't think it would be any good (poas form a hierachy)

> 
> And one unrelated question:
> I have created a ServantManager object and registered it with POA. According
> to standard when object is activated _add_ref() is called nspecified number
> of times. The question is how many times etherealize() method of
> ServantManager should call _remove_ref() when called with
> remaining_activations = true? It works with one call -- but is it
> guaranteed?
> 
> 
> Thanks!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list