Re: omni bug (patch attached)

On Tuesday 25 November, David Riddoch wrote:

> In omniORB3, once you call deactivate_object(), no further new requests 
> will be admitted, and so you can be sure that the object would be 
> etherealised as soon as any requests that have already started complete. 
>   I am not confident that this is the case for omniORB4.
> 
> Duncan: can you confirm?

In omniORB 4, new requests _are_ admitted once an object is
deactivating, so Serguei is right that it's theoretically possible
that an object is never actually deactivated. This behaviour is
unfortunately required to avoid deadlocks on objects that make
recursive calls to themselves.

One way deadlock can occur is in a POA with a servant activator.
Imagine a call comes in for an object. While it is processing, the
object is deactivated; after the deactivate_object call, the operation
implementation makes a recursive call to itself.  Now, the object is
deactivating, so the recursive call would (in omniORB 3) result in an
OBJECT_NOT_EXIST, except that there's a servant activator, so the
object must be activated. But the old one hasn't gone yet, so the POA
spec requires the incarnation to wait until the previous deactivation
has finished. The thread making the recursive call is now deadlocked.
The only way to avoid the situation is to allow new incoming calls
while an object is pending deactivation.

Here's a bit of discussion about this kind of issue...

  http://www.omniorb-support.com/pipermail/omniorb-list/2001-July/018603.html

and an earlier one...

  http://www.omniorb-support.com/pipermail/omniorb-list/1999-December/014336.html

Henning and Vinoski talk about it in section 11.9.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --