Open Stack

Excerpts from Joe Gordon's message of 2015-05-07 17:43:06 -0700:
> On May 7, 2015 2:37 AM, "Sahid Orentino Ferdjaoui" <
> sahid.ferdjaoui at redhat.com> wrote:
> >
> > Hi,
> >
> > The primary point of this expected discussion around asynchronous
> > communication is to optimize performance by reducing latency.
> >
> > For instance the design used in Nova and probably other projects let
> > able to operate ascynchronous operations from two way.
> >
> > 1. When communicate between inter-services
> > 2. When communicate to the database
> >
> > 1 and 2 are close since they use the same API but I prefer to keep a
> > difference here since the high level layer is not the same.
> >
> > From Oslo Messaging point of view we currently have two methods to
> > invoke an RPC:
> >
> >   Cast and Call: The first one is not bloking and will invoke a RPC
> >     without to wait any response while the second will block the
> >     process and wait for the response.
> >
> > The aim is to add new method which will return without to block the
> > process an object let's call it "Future" which will provide some basic
> > methods to wait and get a response at any time.
> >
> > The benefice from Nova will comes on a higher level:
> >
> > 1. When communicate between services it will be not necessary to block
> >    the process and use this free time to execute some other
> >    computations.
> 
> 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.

Yes, this is what the various executors in the messaging library do,
including the eventlet-based executor we use by default.

Where are you seeing nova block on RPC calls?

Doug