[omniORB] wrapping all incoming calls

[Michael Kilburn]

Hi,

I wonder if it is possible to do these two things in CORBA server that uses
omniORB:

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.

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).

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).

If someone could point me into proper direction -- it would be great. Thank
you.

[Michael Kilburn]

I would really appreciate a bit of help with this... Please?

Post by Michael Kilburn
Hi,
I wonder if it is possible to do these two things in CORBA server that uses
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.
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
- 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).
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).
If someone could point me into proper direction -- it would be great. Thank
you.
--
Sincerely yours,
Michael.

[Duncan Grisby]

Post by Michael Kilburn
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.

Post by Michael Kilburn
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
- 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.

Post by Michael Kilburn
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.

[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)?

Post by Duncan Grisby

Post by Michael Kilburn
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.

Post by Michael Kilburn
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
- 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.

Post by Michael Kilburn
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 --
-- http://www.grisby.org --

[Duncan Grisby]

Post by Michael Kilburn
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.

You're right that it will make it harder to upgrade, but there's no
other way you can do what you want, I'm afraid.

Post by Michael Kilburn
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)?

They aren't invoked on a "random" thread -- they're invoked on the
thread that is going to perform the upcall into the application. EXCEPT
that in the main thread model, there is a thread switch to the main
thread just as the upcall is about to happen.

Regardless of that, you can't change the exception that's being returned
in the serverSendException interceptor, so you can't do that bit of what
you want anyway.

Sorry to be the bearer of bad news...

Duncan.