<br><font size=2 face="sans-serif">Alex was able to hit the nail right on the head!</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">I guess I'll have to go find my check book now :-)</font>
<br>
<br><font size=2 face="sans-serif">Renny Koshy<br>
President & CEO<br>
<br>
--------------------------------------------<br>
RUBIX Information Technologies, Inc.<br>
www.rubixinfotech.com</font>
<br>
<br>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Renny Koshy/RubixInfoTech/US on 06/12/2004 12:32 PM -----</font>
<br>
<br><font size=2 face="Courier New">OK. Here's one theory. If you want me to look closer, you'll have to<br>
tell me where the source code is.<br>
<br>
On Fri, 11 Jun 2004 23:15:30 -0400<br>
scott.fay@rubixinfotech.com wrote:<br>
<br>
> Updated information: Here is the standard output that resulted when <br>
> omniORB tracing was set to 25:<br>
> <br>
> omniORB: (0) State root<26> (active) -> deactivating<br>
> omniORB: (0) Object is still busy -- etherealise later.<br>
> omniORB: (3) sendChunk: to giop:tcp:10.10.17.24:53953 24 bytes<br>
> omniORB: (0) omniRemoteIdentity deleted.<br>
> omniORB: (0) <br>
> ObjRef(IDL:omg.org/CosEventChannelAdmin/ProxyPushSupplier:1.0) --<br>
> deleted.<br>
> omniORB: (3) POA(RootPOA) etherealising object root<26><br>
> (deactivating).<br>
> id: IDL:omg.org/CosEventComm/PushConsumer:1.0<br>
> omniORB: (3) State root<26> (deactivating) -> etherealising<br>
> omniORB: (0) ERROR -- A servant has been deleted that is still<br>
> activated.<br>
> omniORB: (3) Removing root<26> (etherealising) from object<br>
> table omniORB: (0) sendChunk: to giop:tcp:10.10.17.27:9001 116 bytes<br>
<br>
"Object is still busy -- etherealise later."<br>
The POA is still using one of your servants...<br>
<br>
"ERROR -- A servant has been deleted that is still activated."<br>
But you seem to have deleted it!!<br>
<br>
This sounds like your servant lifecycle design is incorrect. The POA<br>
must be finished with an active servant before it can be deleted. It is<br>
very hard to know when the POA is finished with a servant - you can call<br>
`deactivate_object()' - but the POA can still keep hold of the servant<br>
for an arbitary time (until ongoing calls are complete). Henning &<br>
Vinoski section 11.9 (pp499-502) is the best reference I know on this.<br>
<br>
Solutions:<br>
<br>
1. RefCountServantBase<br>
<br>
The approach I always use is to use the mix-in class<br>
`RefCountServantBase'. This implements a simple reference counting<br>
mechanism. RefCountServantBase::_remove_ref() deletes the object when<br>
the ref count falls to zero. The POA is refcount-aware, so it calls<br>
_add_ref() & _remove_ref() as required.<br>
<br>
When you are finished with a servant you need to do two things (in<br>
either order):<br>
<br>
* call deactivate_object() in the object's POA. See this file for an<br>
example of code to call deactivate_object() for you:<br>
<br>
http://cvs.sf.net/viewcvs.py/omniifr/omniifr/repository/IRObject.cc?rev=1.1&view=auto<br>
<br>
* call _remove_ref() to release your own reference to the servant.<br>
(The newly contructed object always has a ref count of '1'.) You<br>
can do this as soon as the obect is activated, if you don't want<br>
to refer to the servant except though the POA.<br>
<br>
2. POA deactivate<br>
<br>
Your problem seems to occur when you are deactivating a POA, or perhaps<br>
shutting down the ORB.<br>
<br>
If you make sure that the POA is completely deactivated BEFORE you<br>
delete any servant objects, then you should be safe. Call POA:: (or<br>
ORB::) deactivate() with the `wait_for_completion' parameter set to<br>
TRUE. Only then should you delete your servant objects.<br>
<br>
3. Servant Activator<br>
<br>
You can install a servant activator in your POA. The POA will then call<br>
incarnate() when it wants a new servant, and etherealize() when the<br>
servant can be deleted.<br>
<br>
See OmniEvents::ProxyPullSupplierManager for an example of this<br>
approach.<br>
<br>
Let me know how you get on.<br>
<br>
-Alex<br>
<br>
-- <br>
:: alex tingle<br>
:: 58 kings way, harrow, mddx. uk. HA1 1XU<br>
:: alex.tingle AT firetree.net +44-7901-552763 <br>
_______________________________________________<br>
acd mailing list<br>
acd@lists.softsys.com<br>
http://lists.softsys.com/mailman/listinfo/acd<br>
</font>
<br>