[omniORB] Problem with POA object map.

[Guillaume Schmid]

Hello!

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)
root/ChildPOA<currFrame>

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 );

fw->_remove_ref();

// 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 ?

Yours,
Guillaume.
--
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

[Duncan Grisby]

On Monday 16 October, Guillaume Schmid wrote:

[...]

Post by Guillaume Schmid
My problem is that when I close the service I notice in the log that I
omniORB: Object table entry root/ChildPOA<currFrame> (dead) deleted.
omniORB: Disable ObjRef(IDL:MzDist/DistChannelImage2d:1.0)
root/ChildPOA<currFrame>
so I believe that my attempt to destroy the servant for each frame left
some entry in the POA.

Actually, that's a sign that you have leaked a load of object
references, not anything in the POA. The message about object table
entries is due to the fact that the object references hold a pointer to
the object table entries, even though they are no longer actually in the
object table.

The problem is that you have leaked an object reference in _this:

[...]

Post by Guillaume Schmid
// The client implements this method
_fHandler->handleFrame( fw->_this() );

You need to release the result of _this, so turn that line into
something like

FrameWrapper_var obj = fw->_this();
_fHandler->handleFrame(obj);

That will fix the leak.

Cheers,

Duncan.

[Guillaume Schmid]

Great ! It works!

Thank you very much!

Yours,
Guillaume.

Post by Duncan Grisby
[...]

Post by Guillaume Schmid
My problem is that when I close the service I notice in the log that I
omniORB: Object table entry root/ChildPOA<currFrame> (dead) deleted.
omniORB: Disable ObjRef(IDL:MzDist/DistChannelImage2d:1.0)
root/ChildPOA<currFrame>
so I believe that my attempt to destroy the servant for each frame left
some entry in the POA.

Actually, that's a sign that you have leaked a load of object
references, not anything in the POA. The message about object table
entries is due to the fact that the object references hold a pointer to
the object table entries, even though they are no longer actually in the
object table.
[...]

Post by Guillaume Schmid
// The client implements this method
_fHandler->handleFrame( fw->_this() );

You need to release the result of _this, so turn that line into
something like
FrameWrapper_var obj = fw->_this();
_fHandler->handleFrame(obj);
That will fix the leak.
Cheers,
Duncan.

--
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/eff99433/attachment.bin