[omniORB] in MAN_THREAD_MODEL omniORB releases references from other thread

[Duncan Grisby]

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.

Well, servant->remove_ref() is called from the thread that notices that
the last invocation has completed.

> It sound almost like a violation of guarantees this thread model is supposed
> to give (it was designed to for old non-threaded code after all). What was the
> reason for this behavior and can it be "fixed"? (yes, it caused issues in our
> product in conjunction with other non-obvious things in other places of our
> code, I've spent a lot of time trying to figure out why on rare occasions our
> product started eating tons of memory :-D)

The CORBA spec doesn't say a huge amount about the main thread model.
All it says is that "upcalls" are handled by the "main" thread, but it
doesn't specify what constitutes an upcall. omniORB currently considers
only IDL-defined methods to be upcalls.

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.

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.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --