[omniORB] in MAN_THREAD_MODEL omniORB releases references from other thread

[Michael Kilburn]

I am terribly sorry to reanimate this thread...

On Tue, Jan 13, 2009 at 9:18 AM, Duncan Grisby <duncan at grisby.org> wrote:

> On Wednesday 7 January, "Michael Kilburn" wrote:
>
> > I have recently discovered that MAN_THREAD_MODEL does not guarantee that
> all
> > calls to servant are made on the same thread. In particular:
> > - in a typical destroy() method implementation disconnecting servant from
> > CORBA layer does not cause it to be destroyed immediately (which is ok),
> but
> > instead it is delayed until some point in future
>
> I assume you mean calling poa->deactivate_object() ?
>
> > - and at that point in future release (which usually the last one, and
> > triggers "delete this") is called from different thread.
>

[skip]


>  Now you mention it, though, it does seem logical that the call to
> _remove_ref() is also done in on the main thread. I've checked in a
> change to CVS that implements that.
>

Do you remember in which version of omniORB this problem was fixed?


> If you can't update to the CVS version, you can force use of the main
> thread by registering a ServantActivator that is itself activated in a
> POA with the main thread policy. That way, servants will be released
> using a call the etherealize() on the ServantActivator, which will
> happen on the main thread.
>

We've just discovered a small problem with this approach -- in ORB's
shutdown method we do not get a signle call to ServantActivator'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.

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...

-- 
Sincerely yours,
Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100429/cd342449/attachment.htm