On Thu, May 21, 2015 at 8:13 AM, Sahid Orentino Ferdjaoui < sahid.ferdja...@redhat.com> wrote:
> On Fri, May 08, 2015 at 09:13:59AM -0400, Doug Hellmann wrote: > > 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.ferdja...@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. > > The aim is to be not library specific and avoid to add different and > custom patterns on the base code each time we want something not > blocking. > We can let the well experimented community working in olso messaging > to maintain that part and as Doug said oslo can use different > "executors" so we can avoid the requirement of a specific library. > I see no problem with nova depending on a specific async library. I am not keen on adding yet another column to our support matrix. > > > 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? > > In Nova we use the indirection api to make call to the database by the > conductor through RPCs. > By the solution presented we can create async operations to read and > write from the database. > > Olekssi asks me to give an example I will reply to him. > > s. > > Doug > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev