[omniORB] emulating Reactor pattern with omniORB

[Duncan Grisby]

On Thursday 8 November, "Michael Kilburn" wrote:

> It looks like there is a way to emulate "proper" Reactor pattern with
> omniORB. Here is the trick:
> - use ORB_CTRL mode
> - install interceptors
> - on receiving request or response -- lock mutex
> - on request send/response -- unlock mutex
> 
> This gives semantic close to reactor pattern as implemented in Orbacus (i.e.
> you could have nested calls of any depth) and your server will behave as in
> single-threaded mode -- i.e. no need for synchronization headache.
> 
> Is anything wrong with this approach?

It strikes me as spectacularly dangerous to lock and unlock mutexes
inside interceptors, since you have no guarantee that the ORB will call
them in the way you expect in absolutely all situations.

I am not a fan of the reactor model. I disagree that there is "no need
for synchronization headache" -- whenever you do any remote call, you
are releasing your lock, meaning that all code has to be thread safe
across all calls. To my mind, that's much more of a headache than simply
managing locks as required by critical regions in the code.

> So far I see only these drawbacks:
> - client (app that initiates call chain) can't work this way (you can't
> unlock mutex that is not locked)
> - one-way calls will require some additional treatment (they do not receive
> response)
> - I am not sure if it is ok to stay in interceptor for long time -- for
> example, what will happen if it will stay there for 5 mins? for 1 second and
> another request will arrive? In which context these interceptors are called,
> is anything locked at that point in omniORB guts?

omniORB doesn't hold any locks while calling the request interceptors.
However, your lock will be acquired and released out of step with the
existing partial-order on locks. I would want to do a complete analysis
of all the interactions between the locks to convince myself that there
were no possibility for deadlocks between your lock and the locks in
omniORB.

There are all kinds of other situations in which the scheme might go
wrong. One additional example to the things you list above is that there
are various situations in which calls can be retried due to network
errors, in which case the clientSendRequest interceptor can be called
more than once without corresponding calls to the clientReceiveReply
interceptor.

As I say, I don't think it's a very safe idea.

Cheers,

Duncan.

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