I am terribly sorry to reanimate this thread...<br><br><div class="gmail_quote">On Tue, Jan 13, 2009 at 9:18 AM, Duncan Grisby <span dir="ltr">&lt;<a href="mailto:duncan@grisby.org" target="_blank">duncan@grisby.org</a>&gt;</span>
 wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>On 
Wednesday 7 January, &quot;Michael Kilburn&quot; wrote:<br>
<br>
&gt; I have recently discovered that MAN_THREAD_MODEL does not guarantee
 that all<br>
&gt; calls to servant are made on the same thread. In particular:<br>
&gt; - in a typical destroy() method implementation disconnecting 
servant from<br>
&gt; CORBA layer does not cause it to be destroyed immediately (which is
 ok), but<br>
&gt; instead it is delayed until some point in future<br>
<br>
</div>I assume you mean calling poa-&gt;deactivate_object() ?<br>
<div><br>
&gt; - and at that point in future release (which usually the last one, 
and<br>
&gt; triggers &quot;delete this&quot;) is called from different thread.<br>
</div></blockquote><div><br>[skip]<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
</div>
Now you mention it, though, it does seem logical that the call to<br>
_remove_ref() is also done in on the main thread. I&#39;ve checked in a<br>
change to CVS that implements that.<br></blockquote><div><br>Do you 
remember in which version of omniORB this problem was fixed?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



If you can&#39;t update to the CVS version, you can force use of the main<br>
thread by registering a ServantActivator that is itself activated in a<br>
POA with the main thread policy. That way, servants will be released<br>
using a call the etherealize() on the ServantActivator, which will<br>
happen on the main thread.
<br></blockquote><div> <br>We&#39;ve just discovered a small problem with 
this approach -- in ORB&#39;s shutdown method we do not get a signle call to
 ServantActivator&#39;s etherealize() method -- all servants active in that 
POA leak... In fact activator itself leaks too. My understanding is that
 when POA is teared down, it deactivates everything and subsequent 
etherealize() calls made from other thread silently fail.<br>

<br>Can you suggest anything to fix this issue, please? I guess I can 
create another main-thread POA (if it is possible at all -- it seems 
illogical) and register activator there -- but as I understand there are
 no guarantees on the order of POAs destruction...<br>

<br clear="all"></div></div>-- <br>Sincerely yours,<br>Michael.<br>