[omniORB] Re: Servant activator. Was re: CORBA and firewalls/NATs

[Renzo Tomaselli]

Thank you, Duncan. Indeed we delayed any case needing to call incarnate 
again down to actual method execution, when the involved mutex was 
unlocked by omniOrbPOA. Thus incarnate just creates an empty servant, 
without further actions.
This way everything runs fine.
-- Renzo


Duncan Grisby wrote:
> On Friday 15 December, Renzo Tomaselli wrote:
>
>   
>> we use the servant activator for dynamically instantiate servants
>> since several years and through several versions of OmniORB, till 4.07.
>> One disappointing feature of this mechanism concerns the method
>> omniOrbPOA::dispatch_to_sa (in poa.cc), which holds a mutex on
>> omniServantActivatorTaskQueue while calling incarnate method inside
>> application code. If this in turn needs the servant activator again,
>> then we get a deadlock on any pthread implementation (not on Windows,
>> though).
>>     
>
> Sadly, this behaviour is required in the CORBA spec:
>
> Section 11.3.5 of CORBA 2.6:
>
>   "
>    · Invocations of incarnate on the servant manager are serialized.
>    · Invocations of etherealize on the servant manager are serialized.
>    · Invocations of incarnate and etherealize on the servant manager are
>      mutually exclusive.
>   "
>
> It's a side-effect of the mutex semantics on Windows that they permit
> recursive calls by the thread holding the mutex.
>
> I'm afraid I don't have any good suggestions about what you can do about
> it, other than to refrain from making CORBA calls inside your servant
> activators. It would probably be quite easy to remove the lock, at the
> expense of no longer adhering to the spec.
>
> Cheers,
>
> Duncan.
>
>