Open Stack

> On 07 Jul 2015, at 17:07, Mehdi Abaakouk <sileht at sileht.net> wrote:
> 
> The RPC API of oslo.messaging do it for you, you don't have to care about acknowledgement (or anything else done by the driver because the underlying used pattern depends of  it) .

Phrases like this really scare me. Sorry :) As a developer of a high-load distributed system I want to have everything under my control what’s related with transport, transactions etc. etc.

> For the "Working Queues" patterns, I guess what you need is to ensure that the Target doesn't have the "server" attribute set and use "call" or "cast" depending of your needs.

Can you give more details on how this attribute is related to what we need? Or just a link is fine too.

> It works like this for rabbitmq:
>  * the message is acknowledged from the rabbitmq PoV when the worker start the processing of the message

According the pattern I gave a link to message acknowledgement should happen after message has been processed, not before. It guarantees that none of my messages will be lost in case of worker crashes.

>  * when it finish it send a message back to the caller with the result of the processing or the raised exception if that doesn't work
> 
> On the client side, when you use "call" is wait for the returns.
> 
> If you don't need to get the result or the exception occurred during the message processing just use "cast", it doesn't wait for the return and worker doesn't send it.

Yes, that’s clear. I’m familiar with what oslo messaging does but I’m not understanding why this is relevant to what we need.

> When RPC is needed, acknowledgement after the message have been processed is not enough reliable to ensure the message have been processed correctly and can lead to stuck message on the queue.

Can you please again give more details on this? Why is a message going to get stuck in the queue? Message broker resubmits not acknowledged messages in case of connection losses with corresponding clients (workers) so they may be polled again by other clients. What am I missing?

> Otherwise, the Notification API of oslo.messaging allows to control acknowledgement or requeue of message but does not provide method and endpoint versioning (that allows rolling upgrade for example), and remote executed method are hardcoded to match the notification mechanism of openstack.

As far as I understand it’s basically “Publish->Subscribe” pattern according to RabbitMQ terminology. Correct me if I’m wrong. If so then it won’t help us.

Renat Akhmerov
@Mirantis, Inc.