[omniORB] strange asymmetric behavior

[Renzo Tomaselli]

Kendall,
    fetching a code slice is somewhat problematic since the overall
architecture is pretty complex.
In short, the involved servant is a persistent object which represents a
whole DLL. It is managed through a servant activator in a specific POA
(PERSISTENT, USER_ID, USE_SERVANT_MANAGER). This object represents a service
to be loaded on demand (a factory). We have several of them and they are
operational since a few years without any problem.
A specific infrastructure takes them up and down on demand.
Now I needed to pass an obj ref of one such servant along with a method
invoked out of any servant upcall, although being in the server (service)
code. So I took _this() on it, then I noticed that the loading
infrastructure could not delete the servant because of its refcount being 2
at deactivation time (sometimes).
Then I noticed that this refcount goes sometimes up by one as a side effect
of taking _this(), depending of servant history (e.g. current activations,
see ServantBase::_do_this() ).
It's somewhat difficoult for the method which invokes _this() to determine
if _remove_ref() should be called afterwards or not. I expected that this
would be done by the symmetric local operation, e.g. destroying the obj ref.
I'm actually very confused about why taking _this() out of any upcall should
activate the object again.
Thanks,

Renzo

----- Original Message -----
From: <baileyk at schneider.com>
To: "Renzo Tomaselli" <renzo.tomaselli at tecnotp.it>
Cc: "Omniorb list" <omniorb-list at omniorb-support.com>
Sent: Monday, July 21, 2003 6:19 PM
Subject: Re: [omniORB] strange asymmetric behavior


>
> Just a guess, but since you've posted no code I'll offer it.  If your
> servant has not overridden the _default_poa method, you may be activating
> it a second time in the root POA without intending to.  If you've
activated
> in a POA other than the root, and later call _this() outside the context
of
> an upcall, then the additional activation in the root POA is what's
causing
> the reference count to go up.  If so, there's no leak since the root POA
> will release these references when the ORB is shut down.
>
> If you post a complete example including source for the servant perhaps we
> can track down what's going on.
>
> Kendall