<p dir="ltr"><br>
On May 7, 2015 2:37 AM, "Sahid Orentino Ferdjaoui" <<a href="mailto:sahid.ferdjaoui@redhat.com">sahid.ferdjaoui@redhat.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> The primary point of this expected discussion around asynchronous<br>
> communication is to optimize performance by reducing latency.<br>
><br>
> For instance the design used in Nova and probably other projects let<br>
> able to operate ascynchronous operations from two way.<br>
><br>
> 1. When communicate between inter-services<br>
> 2. When communicate to the database<br>
><br>
> 1 and 2 are close since they use the same API but I prefer to keep a<br>
> difference here since the high level layer is not the same.<br>
><br>
> From Oslo Messaging point of view we currently have two methods to<br>
> invoke an RPC:<br>
><br>
>   Cast and Call: The first one is not bloking and will invoke a RPC<br>
>     without to wait any response while the second will block the<br>
>     process and wait for the response.<br>
><br>
> The aim is to add new method which will return without to block the<br>
> process an object let's call it "Future" which will provide some basic<br>
> methods to wait and get a response at any time.<br>
><br>
> The benefice from Nova will comes on a higher level:<br>
><br>
> 1. When communicate between services it will be not necessary to block<br>
>    the process and use this free time to execute some other<br>
>    computations.</p>
<p dir="ltr">Isn't this what the use of green threads (and eventlet) is supposed to solve. Assuming my understanding is correct, and we can fix any issues without adding async oslo.messaging, then adding yet another async pattern seems like a bad thing.<br></p>
<p dir="ltr">><br>
>       future = rpcapi.invoke_long_process()<br>
>          ... do something else here ...<br>
>       result = future.get_response()<br>
><br>
> 2. We can use the benefice of all of the work previously done with the<br>
>    Conductor and so by updating the framework Objects and Indirection<br>
>    Api we should take advantage of async operations to the database.<br>
><br>
>        MyObject = MyClassObject.get_async()<br>
>          ... do something else here ...<br>
>        MyObject.wait()<br>
><br>
>        MyObject.foo = "bar"<br>
>        MyObject.save_async()<br>
>          ... do something else here ...<br>
>        MyObject.wait()<br>
><br>
> All of this is to illustrate and have to be discussed.<br>
><br>
> I guess the first job needs to come from Oslo Messaging so the<br>
> question is to know the feeling here and then from Nova since it will<br>
> be the primary consumer of this feature.<br>
><br>
> <a href="https://blueprints.launchpad.net/nova/+spec/asynchronous-communication">https://blueprints.launchpad.net/nova/+spec/asynchronous-communication</a><br>
><br>
> Thanks,<br>
> s.<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>