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. 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. Since each notification has a unique message_id, it's easy to detect events we've seen before and .reject() them. There's a branch coming for that as well. This is really only a concern for the notification mechanism ... rpc should not need this, though I can think of lots of places it would be handy with orchestration and the scheduler. But, notifications are where the billing-related things live. By default, everything is the same, ack-on-error=True. But, for some consumers we need to support ack-on-error=False. Personally, I think this is must-have functionality. Look forward to your thoughts. -S _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
