Thank you, Duncan!<br><br>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.<br><br>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)?<br>
<br><br><div class="gmail_quote">On Tue, Jan 19, 2010 at 2:50 AM, Duncan Grisby <span dir="ltr"><<a href="mailto:duncan@grisby.org">duncan@grisby.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, 2010-01-06 at 19:51 -0600, Michael Kilburn wrote:<br>
<br>
> 1. wrap every incoming call with smth like:<br>
> try {<br>
> ... // process call<br>
> } catch(std::exception const& x) {<br>
> throw MyCorbaException(x.what());<br>
> }<br>
><br>
> the idea is to replace CORBA_Unknown exceptions generated by escaped C<br>
> ++ exception with something more useful... Obviously this code should<br>
> be executed in context of a thread that actually processes the<br>
> request.<br>
> I have checked interceptors in the documentation but it is very brief<br>
> and does not give any guarantees on thread context given interceptor<br>
> will be called in.<br>
<br>
</div>That's not the kind of thing you can do with interceptors, since they<br>
don't wrap the call into application code. They're therefore not in a<br>
position to catch exceptions from the application.<br>
<br>
There's no obvious place you can hook to do it. I think by far the<br>
easiest thing is to modify the omniORB code that throws UNKNOWN to throw<br>
your exception instead. That would be pretty simple. Just search for<br>
UNKNOWN In the orbcore source and replace the couple of places. You'd<br>
also need to build the stubs for your exception definition into the<br>
orbcore library of course.<br>
<div class="im"><br>
> 2. this one is very similar to (1) but not required to happen on<br>
> request processing thread -- essentially I need to set a flag before<br>
> processing a request and reset it when it returns. This is going to be<br>
> used in conjunction with MAIN_THREAD_MODEL and it is important that<br>
> flag for given request is not set before previous request finish<br>
> processing... and once flag is set next request to be processed should<br>
> be "ours". Ideally I would like this to work like in (1), but<br>
> alternatively I can use global mutex:<br>
> - in receive request interceptor -- lock mutex, set flag, proceed<br>
> - in reply interceptor (assuming that it is guaranteed to be called,<br>
> even if "proceed" step fails before actually reaching user code) --<br>
> reset flag, unlock mutex<br>
> But I am not sure if it is ok to lock mutexes in interceptors (and if<br>
> it is ok with MAIN_THREAD_MODEL).<br>
<br>
</div>It's not a good idea to lock mutexes in interceptors. It will almost<br>
certainly cause a deadlock sooner or later. Anyway, with the<br>
MAIN_THREAD_MODEL, the interceptors run in the context of the threads<br>
handling the requests, before the dispatch into the main thread, so they<br>
won't be called in the order of requests (and may in fact be called<br>
concurrently).<br>
<br>
Again, I think it's best to modify the ORB code. Look at<br>
MainThreadTask::excecute() in callHandle.cc.<br>
<div class="im"><br>
> That's it... I am looking for a solution that will work regardless of<br>
> current threading model and other configuration options and would be<br>
> nice to have this at the POA granularity level (i.e. to be able to do<br>
> it for requests server by specific POA -- but it is optional).<br>
<br>
</div>The main thread dispatcher operates on a call descriptor object from<br>
which you can retrieve the POA for the call, so you could potentially<br>
get hold of the POA during the dispatch and decide what to do based on<br>
that.<br>
<br>
Cheers,<br>
<br>
Duncan.<br>
<font color="#888888"><br>
--<br>
-- Duncan Grisby --<br>
-- <a href="mailto:duncan@grisby.org">duncan@grisby.org</a> --<br>
-- <a href="http://www.grisby.org" target="_blank">http://www.grisby.org</a> --<br>
<br>
</font></blockquote></div><br>-- <br>Sincerely yours,<br>Michael.<br>