[omniORB] Core dump.... omniORB4... -- resolved by Alex Tingle

[renny.koshy at rubixinfotech.com]

Alex was able to hit the nail right on the head!

The problem was that we have a process with "manages" a connection pool to 
an event service.  In there a "pushconsumer" object was being deleted, 
while still in use by the POA.  Changing it to use the 
RefCountServantBase, per Alex's recommendation #1 solved the entire issue.

I guess I'll have to go find my check book now :-)

Renny Koshy
President & CEO

--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com


----- Forwarded by Renny Koshy/RubixInfoTech/US on 06/12/2004 12:32 PM 
-----

OK. Here's one theory. If you want me to look closer, you'll have to
tell me where the source code is.

On Fri, 11 Jun 2004 23:15:30 -0400
scott.fay at rubixinfotech.com wrote:

> Updated information:  Here is the standard output that resulted when 
> omniORB tracing was set to 25:
> 
> omniORB: (0) State root<26> (active) -> deactivating
> omniORB: (0) Object is still busy -- etherealise later.
> omniORB: (3) sendChunk: to giop:tcp:10.10.17.24:53953 24 bytes
> omniORB: (0) omniRemoteIdentity deleted.
> omniORB: (0) 
> ObjRef(IDL:omg.org/CosEventChannelAdmin/ProxyPushSupplier:1.0) --
>  deleted.
> omniORB: (3) POA(RootPOA) etherealising object root<26>
> (deactivating).
>  id: IDL:omg.org/CosEventComm/PushConsumer:1.0
> omniORB: (3) State root<26> (deactivating) -> etherealising
> omniORB: (0) ERROR -- A servant has been deleted that is still
>  activated.
> omniORB: (3) Removing root<26> (etherealising) from object
>  table omniORB: (0) sendChunk: to giop:tcp:10.10.17.27:9001 116 bytes

"Object is still busy -- etherealise later."
The POA is still using one of your servants...

"ERROR -- A servant has been deleted that is still activated."
But you seem to have deleted it!!

This sounds like your servant lifecycle design is incorrect. The POA
must be finished with an active servant before it can be deleted. It is
very hard to know when the POA is finished with a servant - you can call
`deactivate_object()' - but the POA can still keep hold of the servant
for an arbitary time (until ongoing calls are complete). Henning &
Vinoski section 11.9 (pp499-502) is the best reference I know on this.

Solutions:

1. RefCountServantBase

The approach I always use is to use the mix-in class
`RefCountServantBase'. This implements a simple reference counting
mechanism. RefCountServantBase::_remove_ref() deletes the object when
the ref count falls to zero. The POA is refcount-aware, so it calls
_add_ref() & _remove_ref() as required.

When you are finished with a servant you need to do two things (in
either order):

 * call deactivate_object() in the object's POA. See this file for an
   example of code to call deactivate_object() for you:

http://cvs.sf.net/viewcvs.py/omniifr/omniifr/repository/IRObject.cc?rev=1.1&view=auto

 * call _remove_ref() to release your own reference to the servant.
   (The newly contructed object always has a ref count of '1'.) You
   can do this as soon as the obect is activated, if you don't want
   to refer to the servant except though the POA.

2. POA deactivate

Your problem seems to occur when you are deactivating a POA, or perhaps
shutting down the ORB.

If you make sure that the POA is completely deactivated BEFORE you
delete any servant objects, then you should be safe. Call POA:: (or
ORB::) deactivate() with the `wait_for_completion' parameter set to
TRUE. Only then should you delete your servant objects.

3. Servant Activator

You can install a servant activator in your POA. The POA will then call
incarnate() when it wants a new servant, and etherealize() when the
servant can be deleted.

See OmniEvents::ProxyPullSupplierManager for an example of this
approach.

Let me know how you get on.

-Alex

-- 
:: alex tingle
:: 58 kings way, harrow, mddx. uk. HA1 1XU
:: alex.tingle AT firetree.net  +44-7901-552763 
_______________________________________________
acd mailing list
acd at lists.softsys.com
http://lists.softsys.com/mailman/listinfo/acd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040612/750b9cfe/attachment.htm