[omniORB] Problem with POA object map.

Guillaume Schmid guillaume at maunakeatech.com
Mon Oct 16 15:05:21 BST 2006


I work for a small company working on medical imaging devices and I
would like to build a corba interface to our acquisition engine. While
testing OmniORB, I came across a problem, I tried many things but could
not solve it. I tried to look on the book from M.Henning and S.Vinosky,
as well as google some hint but did not found any.
Here is the problem:

I have a ImagingService servant on the root POA.
The client uses the ImagingService class to register a callback class
named FrameHandler.
The flow of operation is:

1->The client register the FameHandler.
2->The client Start the frame acquisition.

While some frame are availlable:
  3--> The servant grabs some frames in a thread, for each frame it
instantiate a small frame wrapper (let's call it FrameWrapper). It is a
small servant that provide a corba acess to the frame.
  4--> Then it call the FrameHandler method handleFrame( FrameWrapper )
on the client.
  5--> The client implements the frameHandler::HandleFrame
( FrameWrapper ) method and do some work with the frame and returns.
  6-->The the server destroy the FrameWrapper.

My problem is that when I close the service I notice in the log that I
have a LOT of message like:

omniORB: Object table entry root/ChildPOA<currFrame> (dead) deleted.
omniORB: Disable ObjRef(IDL:MzDist/DistChannelImage2d:1.0)

so I believe that my attempt to destroy the servant for each frame left
some entry in the POA.
My problems it that the imaging service generates a lot of frames, and a
lot of wrappers. So there is a lot of entry in the object table entry
and the process grows at each frame.

The method that call back the client looks like this:
void ImagingServiceImpl::handle( boost::shared_ptr<Frame> & frame )
// Create the frame wrapper with the frame.
FrameWrapper *fw( new FrameWrapper( frame ) );

// Create a single ID (there is only one FrameWrapper at a time)
PortableServer::ObjectId_var frameId =
PortableServer::string_to_ObjectId( "currFrame" );

_poa->activate_object_with_id( frameId, fw );

// The client implements this method
_fHandler->handleFrame( fw->_this() );

_poa->deactivate_object( frameId );

I tried many things, first I had automatic servant registration on the
default POA, then I created a POA with USED ID policy to re-use always
the same ID (I thought that might solve the problem but I was wrong).
The servant is properly destroyed each time.

Well, of course, I can change my API to instantiate a single wrapper and
swicth the frame inside this wrapper (that would even probably be more
efficient) but I would like to anderstand why I have this problem.

I use OmniORB 4.0.5 and tried as well with 4.0.7 with same effects ( and omniPY as a client ).

Could someone enlighten me on this ?
What is the best way to manage a lot of short lived objects like this ?


Guillaume Schmid -  Software Development Supervisor
Mauna Kea Technologies - http://www.maunakeatech.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061016/0f1ea7de/attachment.bin

More information about the omniORB-list mailing list