Hi,
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) .
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.
It works like this for rabbitmq:
* the message is acknowledged from the rabbitmq PoV when the worker
start the processing of the message
* 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.
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.
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.
Cheers,
---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht
Le 2015-07-07 12:13, Renat Akhmerov a écrit :
Just to clarify: what we’re looking for is how to implement “Work
queue” pattern described at [1] with oslo messaging. As Nikolay said,
it requires that a message to be acknowledged after it has been
processed.
[1] http://www.rabbitmq.com/tutorials/tutorial-two-python.html
<http://www.rabbitmq.com/tutorials/tutorial-two-python.html>
Renat Akhmerov
@ Mirantis Inc.
On 07 Jul 2015, at 15:58, Nikolay Makhotkin <nmakhot...@mirantis.com>
wrote:
Hi,
I am using RabbitMQ as the backend and searched oslo.messaging for
message acknowledgement feature but I found only [1] what is wrong
using of acknowledgement since it acknowledges incoming message before
it has been processed (while it should be done only after processing
the message, otherwise we can lost given message if, say, the server
suddenly goes down).
So, my questions: does oslo.messaging indeed not support correct
acknowledgement feature? Or it is impossible to do for oslo.messaging
paradighm? Or is it somehow connected with that oslo.messaging has to
support a lot of transport types?
Can't it be implemented somehow in oslo.messaging?
[1]
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135
<https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135>
Best Regards,
Nikolay
@Mirantis Inc.
__________________________________________________________________________
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
