<div dir="ltr">Hi Michael,<div> thanks for your reply, indeed my example was not very good because I used the servant itself in there and not a CORBA object, which of course would always block and I would have to execute in a separate thread if I wanted the "oneway" behavior. However the problem happens also working with a CORBA Object on the same process. So, if I implement the server and client code in the same script (running in different threads), the call is still waited to finish for:</div><div><br></div><div><span class="gmail-im" style="color:rgb(80,0,80)">import sys<br>import time<br>import datetime<br></span>from threading import Thread<span class="gmail-im" style="color:rgb(80,0,80)"><br><br>import AsyncModule<br>import AsyncModule__POA<br><br>from omniORB import CORBA, PortableServer<br><br>class AsyncExampleImpl(AsyncModule__POA.AsyncExample):<br> def delay(self, sleepSec):<br> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "Start")<br> time.sleep(sleepSec)<br> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "Finish")<br><br></span>def client(ior):<br> time.sleep(1) #To ensure the orb starts before the client code gets executed<br> orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)<br> cli_obj = orb.string_to_object(ior)<br> cli_obj = cli_obj._narrow(AsyncModule.AsyncExample)<br> if cli_obj is None:<br> sys.exit(1)<span class="gmail-im" style="color:rgb(80,0,80)"><br><br> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "Before")<br></span> result = cli_obj.delay(2)<span class="gmail-im" style="color:rgb(80,0,80)"><br> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "After")<br><br>orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)<br>poa = orb.resolve_initial_references("RootPOA")<br><br>servant = AsyncExampleImpl()<br>obj = servant._this()<br><br></span>ior = orb.object_to_string(obj)<br><br>poaManager = poa._get_the_POAManager()<br>poaManager.activate()<br><br>t = Thread(target=client, args=(ior,))<br>t.start()<br>orb.run()<br>t.join()<br></div><div><br></div><div>2020-12-08 15:15:50.441154 Before<br>2020-12-08 15:15:50.441386 Start<br>2020-12-08 15:15:52.442928 Finish<br>2020-12-08 15:15:52.443160 After<br></div><div><br></div><div>In this later example, I would expect an optimization from omniORB/omniORBpy avoiding the network call as you suggest, however I would not expect to lose the one-way behavior of the method call.</div><div><br></div><div>Cheers,</div><div>Tomas.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 11:09 AM Michael Teske via omniORB-list <<a href="mailto:omniorb-list@omniorb-support.com">omniorb-list@omniorb-support.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tomas,<br>
<br>
if the call goes across the network, one can just send the request and not wait for a result, so a oneway doesn't wait.<br>
But corba calls for local objects result in a normal function call. I don't think that there is any exception for <br>
oneways. To achieve that one would have to route the local request across the network, e.g. the loopback interface, and <br>
I'd say in most cases this would not be wanted. Maybe it's possible to convert a local object to an object reference on <br>
the network which would do exactly that, when called. But if you already know your object is local you could start a <br>
thread for the call yourself, circumventing any CORBA overhead. Can't think of any "automatic" solution right now, but <br>
maybe Duncan has an idea :)<br>
<br>
Greetings,<br>
Michael<br>
<br>
Am 30/11/2020 um 20:04 schrieb Tomas Staig via omniORB-list:<br>
> Dear all,<br>
> we use omniORBpy for a long time now, but just recently we noticed a problem with oneway operations when both the <br>
> client and the servant are on the same process. We have a container/component model on top of CORBA, so we don't impose <br>
> restrictions on the deployment of the CORBA objects, which means this situation can happen depending on the developers <br>
> and the people doing the deployment.<br>
> <br>
> I made an isolated test using omniORBpy that exposes the situation:<br>
> #ifndef _ASYNC_MODULE_IDL_<br>
> #define _ASYNC_MODULE_IDL_<br>
> <br>
> #pragma prefix "acsws"<br>
> <br>
> module AsyncModule<br>
> {<br>
> interface AsyncExample {<br>
> oneway void delay(in long sleepSec);<br>
> };<br>
> };<br>
> #endif<br>
> <br>
> Then, the implementation would be:<br>
> import sys<br>
> import time<br>
> import datetime<br>
> <br>
> import AsyncModule<br>
> import AsyncModule__POA<br>
> <br>
> from omniORB import CORBA, PortableServer<br>
> <br>
> class AsyncExampleImpl(AsyncModule__POA.AsyncExample):<br>
> def delay(self, sleepSec):<br>
> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "Start")<br>
> time.sleep(sleepSec)<br>
> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "Finish")<br>
> <br>
> orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)<br>
> poa = orb.resolve_initial_references("RootPOA")<br>
> <br>
> servant = AsyncExampleImpl()<br>
> obj = servant._this()<br>
> <br>
> poaManager = poa._get_the_POAManager()<br>
> poaManager.activate()<br>
> <br>
> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "Before")<br>
> result = obj.delay(2)<br>
> print(datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f"), "After")<br>
> <br>
> The output I receive is the following:<br>
> 2020-11-30 19:00:38.022027 Before<br>
> 2020-11-30 19:00:38.022068 Start<br>
> 2020-11-30 19:00:40.023909 Finish<br>
> 2020-11-30 19:00:40.024071 After<br>
> <br>
> Which shows that the process remained waiting for the oneway operation to finish before continuing.<br>
> <br>
> When splitting this in two processes (client and server), the output is the following:<br>
> 2020-11-30 19:02:13.797152 Before<br>
> 2020-11-30 19:02:13.797635 After<br>
> 2020-11-30 19:02:13.797742 Start<br>
> 2020-11-30 19:02:15.800049 Finish<br>
> <br>
> Which is what I would expect from a oneway operation.<br>
> <br>
> Thanks a lot!<br>
> <br>
> Best regards,<br>
> Tomas.<br>
> <br>
> _______________________________________________<br>
> omniORB-list mailing list<br>
> <a href="mailto:omniORB-list@omniorb-support.com" target="_blank">omniORB-list@omniorb-support.com</a><br>
> <a href="https://www.omniorb-support.com/mailman/listinfo/omniorb-list" rel="noreferrer" target="_blank">https://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br>
> <br>
<br>
<br>
_______________________________________________<br>
omniORB-list mailing list<br>
<a href="mailto:omniORB-list@omniorb-support.com" target="_blank">omniORB-list@omniorb-support.com</a><br>
<a href="https://www.omniorb-support.com/mailman/listinfo/omniorb-list" rel="noreferrer" target="_blank">https://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br>
</blockquote></div>