[omniORB] wrapping all incoming calls

[Michael Kilburn]

Thank you, Duncan!

I do not really like the idea of modifying omniORB code -- this will make it
harder to update it later... But probably will have to resort to that.

What about 'sendreply/sendexception' interceptor -- is it called in context
of main thread (in case of MAIN_THREAD_MODEL) or send operation is delegated
elsewhere (and interceptor is invoked on some random thread)?


On Tue, Jan 19, 2010 at 2:50 AM, Duncan Grisby <duncan at grisby.org> wrote:

> 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 --
>
>
-- 
Sincerely yours,
Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100120/3ddd45dd/attachment.htm