Guillaume Schmid
2006-10-16 18:05:13 UTC
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
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