[omniORB] Omni threads keep waiting on omni::internalLock mutex, as a resul t Server hangs !!!

[Duncan Grisby]

On Friday 29 October, Kamaldeep Singh Khanuja wrote:

> We are facing a problem in which our application hangs where in our server
> accepts the calls but it could not 'dispatch' the call up to the respective
> servants. This is followed by the following error message at the server
> console:
> "omniORB: ERROR -- A servant has been deleted that is still activated."
> 
> The cause for the hang seems to be due to the fact that omni::internal mutex
> remains locked forever and new calls to the server wait on this mutex. This
> happens when the servant gets deleted (in our application we have a
> dedicated thread which performs the servant deactivation and deletion) when
> there is a client who is currently waiting for the response from server i.e.
> within the IDL call itself. So when the omni thread which was handling the
> request returns from the IDL call it follows the following stack:

This is a uniquely Windows problem. You have deleted a servant, which
you later try to invoke upon. On Unix platforms, you would get a
segmentation fault. On Windows, you get a C++ exception, which is
caught higher up the omniORB call chain. Your application has done
something invalid, which has left omniORB in an inconsistent state.
It is unreasonable to expect omniORB to cope with absolutely all cases
of corruption by application code.

[...]
> Wouldn't it be good that omni just deactivates the deleted servant by simply
> removing its reference from object table, probably prints the same error
> message and does not hang.

It can't be deactivated if the application has deleted it, because
deactivation can involve calling methods on it, or deferring actual
deactivation until later. If any change is to be made, it should be to
immediately abort if the application deletes an active servant.

Cheers,

Duncan.

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