[omniORB] strange asymmetric behavior
baileyk at schneider.com
baileyk at schneider.com
Mon Jul 21 12:19:50 BST 2003
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
"Renzo Tomaselli"
<renzo.tomaselli at tecnotp.it> To: "Omniorb list" <omniorb-list at omniorb-support.com>
Sent by: cc:
omniorb-list-bounces at omniorb- Fax to:
support.com Subject: Re: [omniORB] strange asymmetric behavior
07/21/2003 08:24 AM
----- Original Message -----
From: "Clarke Brunt" <clarke at lsl.co.uk>
To: "Omniorb list" <omniorb-list at omniorb-support.com>
Sent: Monday, July 21, 2003 2:46 PM
Subject: Re: [omniORB] strange asymmetric behavior
> I thought this was just the way it was meant to work. The ref count
starts
> at 1 when the servant is constructed with 'new'. If the call to _this()
> activates it (using implicit activation), then there is now a reference
to
> it in the POA, and the reference count is therefore increased (now at
least
> 2). It is not the job of xxx_var to do _remove_ref - don't confuse
reference
> counting of object references with reference counting of servants. If you
> want the object to be automatically deleted once it it deactivated, then
you
> need to ensure that you are no longer holding on to the reference gained
in
> 'new', so you need to put an explicit call to _remove_ref() somewhere.
> Obviously this can't be done before the object is activated, otherwise it
> will be deleted before it is activated, but you can do this _remove_ref()
as
> soon as you are certain that the object has been activated (either by the
> first call to _this(), or an explicit activate_object, or whatever).
>
> --
> Clarke Brunt, Principal Software Engineer, Yeoman Navigation
>
True, indeed the overall game works fine in the context of returning _this
()
at object building time.
However if such an obj ref. is taken later for other purposes (after
creation/activation/return to the client), I wonder why the server
application must take into account the context to decide whether to make an
explicit call to _remove_ref() or not.
If we take _this() from within any method implementation of the target
servant, then it's ok, while if we do it from within a different context
then we must explicitely call _remove_ref().
Things are even more confused since they depend on the count of outstanding
activations. These are all global factors from the application point of
view, which should call _remove_ref() or not according to the overall
history of such a servant.
Renzo Tomaselli
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
More information about the omniORB-list
mailing list