[omniORB] wrapping all incoming calls

[Duncan Grisby]

On Wed, 2010-01-06 at 19:51 -0600, Michael Kilburn wrote:

> 1. wrap every incoming call with smth like:
> try {
> ... // process call
> } catch(std::exception const& x) {
>    throw MyCorbaException(x.what());
> }
> 
> the idea is to replace CORBA_Unknown exceptions generated by escaped C
> ++ exception with something more useful... Obviously this code should
> be executed in context of a thread that actually processes the
> request.
> I have checked interceptors in the documentation but it is very brief
> and does not give any guarantees on thread context given interceptor
> will be called in.

That's not the kind of thing you can do with interceptors, since they
don't wrap the call into application code. They're therefore not in a
position to catch exceptions from the application.

There's no obvious place you can hook to do it. I think by far the
easiest thing is to modify the omniORB code that throws UNKNOWN to throw
your exception instead. That would be pretty simple. Just search for
UNKNOWN In the orbcore source and replace the couple of places. You'd
also need to build the stubs for your exception definition into the
orbcore library of course.

> 2. this one is very similar to (1) but not required to happen on
> request processing thread -- essentially I need to set a flag before
> processing a request and reset it when it returns. This is going to be
> used in conjunction with MAIN_THREAD_MODEL and it is important that
> flag for given request is not set before previous request finish
> processing... and once flag is set next request to be processed should
> be "ours". Ideally I would like this to work like in (1), but
> alternatively I can use global mutex:
> - in receive request interceptor -- lock mutex, set flag, proceed
> - in reply interceptor (assuming that it is guaranteed to be called,
> even if "proceed" step fails before actually reaching user code) --
> reset flag, unlock mutex
> But I am not sure if it is ok to lock mutexes in interceptors (and if
> it is ok with MAIN_THREAD_MODEL).

It's not a good idea to lock mutexes in interceptors. It will almost
certainly cause a deadlock sooner or later. Anyway, with the
MAIN_THREAD_MODEL, the interceptors run in the context of the threads
handling the requests, before the dispatch into the main thread, so they
won't be called in the order of requests (and may in fact be called
concurrently).

Again, I think it's best to modify the ORB code. Look at
MainThreadTask::excecute() in callHandle.cc.

> That's it... I am looking for a solution that will work regardless of
> current threading model and other configuration options and would be
> nice to have this at the POA granularity level (i.e. to be able to do
> it for requests server by specific POA -- but it is optional).

The main thread dispatcher operates on a call descriptor object from
which you can retrieve the POA for the call, so you could potentially
get hold of the POA during the dispatch and decide what to do based on
that.

Cheers,

Duncan.

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