On 14/08/13 17:08 -0300, Sandy Walsh wrote:
At Eric's request in https://review.openstack.org/#/c/41979/ I'm
bringing this to the ML for feedback.
Currently, oslo-common rpc behaviour is to always ack() a message no
matter what.
Hey,
I don't think we should keep adding new features to Oslo's rpc, I'd
rather think how this fits into oslo.messaging.
For billing purposes we can't afford to drop important notifications
(like *.exists). We only want to ack() if no errors are raised by the
consumer, otherwise we want to requeue the message.
Now, once we introduce this functionality, we will also need to support
.reject() semantics.
The use-case we've seen for this is:
1. grab notification
2. write to disk
3. do some processing on that notification, which raises an exception.
4. the event is requeued and steps 2-3 repeat very quickly. Lots of
duplicate records. In our case we've blown out our database.
Although I see some benefits from abstracting this, I'm not sure
whether we *really* need this in Oslo messaging. My main concern is
that acknowledgement is not supported by all back-ends and this can
turn out being a design flaw for apps depending on methods like ack()
/ reject().
Have you guys thought about re-sending the failed message on a
different topic / queue?
This is what Celery does to retry tasks on failures, for example.
FF
--
@flaper87
Flavio Percoco
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
