orbitcpp-list

[orbitcpp-list] Destroying CORBA objects

[Sam C. <sa...@to...>]

All,

I have a CORBA application that creates many objects on the server side,
continuously. I need a way to destroy these objects to avoid memory leaks.

The application was previously using ORBit, and all I did was provide a
free() method on each object, which the client called when it was finished
with the object.

Now that I need to tie the application into a C++ API, I've decided to use
ORBitcpp.

So, how do I destroy an object in the server in ORBitcpp? I know how to
create one (the Account/Bank example), but doing "delete(this)" to destroy
it seems like suicide to me.

Should I provide a bunch of freeObjectFoo() methods on the factory object
that's creating them all in the first place? This doesn't seem like the
correct solution. If I do this, what do I need to do to destroy the objects
passed to this method?

Thanks.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Hi Sam,

You're right - a 'delete this' (on its own) will cause problems since
the object must be removed from the active object map before deleting
otherwise the poa will continue sending requests to a dead servant.

Michi Henning (Advanced CORBA Programming with C++) recommends that
the 'free' call (called 'remove' in the CORBA lifecycle spec - you may
want to copy this convention) be put on the object interface rather
than the factory, since object refs can be passed between servers and
so having to keep track of the parent/factory can be a pain. Note that
both COM and EJB follow this approach (in methods
'IUnknown::release()' and 'EJBObject.remove()' respectively).

<The bad news>
Unfortunately orbitcpp doesn't have the poa infrastructure to do this
right now, but I am currently working on it. Expect the code to be in
cvs within the next 2 weeks. I'll keep you posted.
</The bad news>

Cheers,

Phil

Sam Couter writes:
 > All,
 > 
 > I have a CORBA application that creates many objects on the server side,
 > continuously. I need a way to destroy these objects to avoid memory leaks.
 > 
 > The application was previously using ORBit, and all I did was provide a
 > free() method on each object, which the client called when it was finished
 > with the object.
 > 
 > Now that I need to tie the application into a C++ API, I've decided to use
 > ORBitcpp.
 > 
 > So, how do I destroy an object in the server in ORBitcpp? I know how to
 > create one (the Account/Bank example), but doing "delete(this)" to destroy
 > it seems like suicide to me.
 > 
 > Should I provide a bunch of freeObjectFoo() methods on the factory object
 > that's creating them all in the first place? This doesn't seem like the
 > correct solution. If I do this, what do I need to do to destroy the objects
 > passed to this method?
 > 
 > Thanks.
 > -- 
 > Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
 > sa...@to...    |   tSA Consulting      |
 > PGP key available on key servers
 > PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Destroying CORBA objects

[Michael R. <mi...@ru...>]

Hi Phil,

does your current work include the create_POA related stuff? A friend of
mine is having troubles using special policies on a new POA...!!

Thanks,
    Michael

----- Original Message -----
From: "Phil Dawes" <ph...@us...>
To: <orb...@li...>
Sent: Donnerstag, 19. Oktober 2000 12:07
Subject: Re: [orbitcpp-list] Destroying CORBA objects


> Hi Sam,
>
> You're right - a 'delete this' (on its own) will cause problems since
> the object must be removed from the active object map before deleting
> otherwise the poa will continue sending requests to a dead servant.
>
> Michi Henning (Advanced CORBA Programming with C++) recommends that
> the 'free' call (called 'remove' in the CORBA lifecycle spec - you may
> want to copy this convention) be put on the object interface rather
> than the factory, since object refs can be passed between servers and
> so having to keep track of the parent/factory can be a pain. Note that
> both COM and EJB follow this approach (in methods
> 'IUnknown::release()' and 'EJBObject.remove()' respectively).
>
> <The bad news>
> Unfortunately orbitcpp doesn't have the poa infrastructure to do this
> right now, but I am currently working on it. Expect the code to be in
> cvs within the next 2 weeks. I'll keep you posted.
> </The bad news>
>
> Cheers,
>
> Phil
>
> Sam Couter writes:
>  > All,
>  >
>  > I have a CORBA application that creates many objects on the server
side,
>  > continuously. I need a way to destroy these objects to avoid memory
leaks.
>  >
>  > The application was previously using ORBit, and all I did was provide a
>  > free() method on each object, which the client called when it was
finished
>  > with the object.
>  >
>  > Now that I need to tie the application into a C++ API, I've decided to
use
>  > ORBitcpp.
>  >
>  > So, how do I destroy an object in the server in ORBitcpp? I know how to
>  > create one (the Account/Bank example), but doing "delete(this)" to dest
roy
>  > it seems like suicide to me.
>  >
>  > Should I provide a bunch of freeObjectFoo() methods on the factory
object
>  > that's creating them all in the first place? This doesn't seem like the
>  > correct solution. If I do this, what do I need to do to destroy the
objects
>  > passed to this method?
>  >
>  > Thanks.
>  > --
>  > Sam Couter          |   Internet Engineer   |
http://www.topic.com.au/
>  > sa...@to...    |   tSA Consulting      |
>  > PGP key available on key servers
>  > PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89
C75C
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Hi Michael,

Yep - none of that will work in orbitcpp yet. I'll be wrapping all of
the current ORBit POA functionality in the next couple of weeks.

If you have a snippet of code illustrating what he's trying to do,
I'll prioritise!

Cheers,

Phil

Michael Rumpf writes:
 > Hi Phil,
 > 
 > does your current work include the create_POA related stuff? A friend of
 > mine is having troubles using special policies on a new POA...!!
 > 
 > Thanks,
 >     Michael
 > 

Re: [orbitcpp-list] Destroying CORBA objects

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
>=20
> <The bad news>
> Unfortunately orbitcpp doesn't have the poa infrastructure to do this
> right now, but I am currently working on it. Expect the code to be in
> cvs within the next 2 weeks. I'll keep you posted.
> </The bad news>

I need this ability (and some others) ASAP. Is there any help I could offer
to speed up the development process?

When you say 2 weeks, does that mean reasonably stable support, or is
bugstomping an additional time?

The other funcionality I need is:
Support for the 'any' type (I could work around this if I had to, but it'd
be nasty)
Thread-safety (I *think* I could work around this, but I'm not sure - it
would involve using fork() to provide each CORBA object with its own
single-threaded ORB)

If anyone can give me pointers towards helping implement any of these
things, I'd be willing to put in some time and effort to do so. My only
alternative to using ORBit-C++ is to write C wrappers around the C++ library
I need to use, and write in C using ORBit. Yuck. I'd prefer to avoid that.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Sam Couter writes:
 > Phil Dawes <ph...@us...> wrote:
 > > 
 > > <The bad news>
 > > Unfortunately orbitcpp doesn't have the poa infrastructure to do this
 > > right now, but I am currently working on it. Expect the code to be in
 > > cvs within the next 2 weeks. I'll keep you posted.
 > > </The bad news>
 > 
 > I need this ability (and some others) ASAP. Is there any help I could offer
 > to speed up the development process?
 > 

Yes please!

 > When you say 2 weeks, does that mean reasonably stable support, or is
 > bugstomping an additional time?
 > 

Time includes testing (i.e. includes a unit test in the /test dir)

 > The other funcionality I need is:
 > Support for the 'any' type (I could work around this if I had to, but it'd
 > be nasty)

hmmmm... Both 'typecode' and 'any' are missing from orbitcpp (any
relies on typecode to work). And union.

 > Thread-safety (I *think* I could work around this, but I'm not sure - it
 > would involve using fork() to provide each CORBA object with its own
 > single-threaded ORB)
 > 

orbitcpp *should* be thread safe. (I removed the last (I think) thread
unsafe construct before the 0.29 release). I've never tested it with
ORBit-mt though. Has anybody else?

 > If anyone can give me pointers towards helping implement any of these
 > things, I'd be willing to put in some time and effort to do so. My only
 > alternative to using ORBit-C++ is to write C wrappers around the C++ library
 > I need to use, and write in C using ORBit. Yuck. I'd prefer to avoid that.

If you're willing, you could do a lot here to help. The majority of
the work in implementing support for Typecode and Any is in wrapping
the C constructs in C++ classes which conform to the C++ corba
spec. The actual compiler should be fairly easy (and for speed
probably best left to me or Andreas to implement).

Here's a brief rundown of what I think is required:

- create orbitcpp_any.hh/orbitcpp_any.cc and
orbitcpp_typecode.hh/orbitcpp_typecode.cc files in the orb directory.

- Write a TypeCode class which wraps the C ORBit typecode struct. Note
that these need to be binary compatible, so the only datamember in the
class should be the 'value' (not pointer) of the C struct.

- Do the same for the Any class

- write a couple of test functions in the test/everything/client.cc
file to confirm that values can be inserted into and extracted from
anys etc...

- Pester me or andreas to write the compiler bit. (Or alternatively
spend some time reading the HACKING file and familiarising yourself
with the compiler design).

Does this sound reasonable?

Cheers,

Phil

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Hi Sam, hi list,

As discussed in an earlier mail on this thread, 'delete this' is a bad
idea in a corba servant, since the orb has a reference to the object
in the active object map. An additional barrier to doing a 'delete
this' from within a corba method is that even if you remove the
servant from the active object map first, the poa is at liberty to
reference the servant on post-invoke.

In order to overcome this, the C++ mapping provides a server side
reference counting mechanism for servants, enabling a 'remove()'
method to be implemented as an idl operation on the servant.

(see section 1.36.1 and 1.36.2 of the C++ language mapping).

Here's the receipe for implementing reference counted transient
objects in CORBA (this now works with cvs version of orbitcpp):


1) Make the implementation inherit from the
PortableServer::RefCountServantBase mixin base class.

E.g.

class TransientObj_impl : public virtual POA_test::TransientObj,
						  public virtual PortableServer::RefCountServantBase{
	...
};


This base class implements the _add_ref() and _remove_ref() methods on
the PortableServer::ServantBase base class with an implementation
which manages a thread-safe count, and calls 'delete this()' when it
hits 0.

2) In your factory (or wherever the servant creation is done) you must
be careful to call remove_ref() on your implementation once you've
finished with it.

E.g.

test::TransientObj_ptr
test_impl::TestFactory_impl::createTransientObj(){
  test_impl::TransientObj_impl *impl = new test_impl::TransientObj_impl;

  test::TransientObj_ptr ptr = impl->_this();   // the poa calls _add_ref() implicitly
  impl->_remove_ref();   // release the servant since we are finished with it
  return ptr;
}

N.B. when you call _this() to implicitly activate the object (or
POA::activate_object() to explicitly activate it) the POA increases
the reference to ensure that it is kept alive while it is in the
active object map.

3) Create a remove() operation on your CORBA interface. In the
implementation of this operation, call POA::deactivate_object(). This
will ensure that after the operation has completed (and in addition,
any concurrent operations have completed), the servant's reference
will be decremented, and the servant will be deleted.

E.g.

void
test_impl::TransientObj_impl::remove() {
  PortableServer::POA_var poa = _default_POA();
  PortableServer::ObjectId_var oid = poa->servant_to_id(this);
  poa->deactivate_object(*oid);
}


Hope this helps,

Cheers,

Phil