Make the ack-then-process option configurable

Registered by Bogdan Dobrelya on 2015-12-01

Historically, most of the OpenStack projects could not handle duplicated messages and would do things over
and over again (further corrupting the world). That is why olso.messaging (or impl_rabbit at least) was aiming for an
at-most-once guarantee (i.e. avoiding duplication at the expense of dropped messages.

Although, this yet to give strong guarantees for no duplicates:
- the acknowledgement is done before processing, though since the acknowledgement is asynchronous, that only
narrows the window it doesn't eliminate it.
- There is a message id 'cache' used to try and detect (and then ignore)
duplicates. It's not clear how effective that is in practice as it
only tracks the last 16 ids for a given listener. In any case if the
listener process is restarted, or if the call is redelivered to a
different server in a group, then the id cache would be of no use.

The suggested solution is to make the ack_then_process semantics to be implemented as a Work Queue API and to be adopted in the tooz & taskflow.

See http://lists.openstack.org/pipermail/openstack-dev/2015-July/068833.html
http://lists.openstack.org/pipermail/openstack-dev/2015-December/080907.html

Blueprint information

Status:
Started
Approver:
Dims
Priority:
Undefined
Drafter:
Bogdan Dobrelya
Direction:
Needs approval
Assignee:
None
Definition:
Pending Approval
Series goal:
Proposed for mitaka
Implementation:
Needs Code Review
Milestone target:
milestone icon 1.16.0
Started by
Bogdan Dobrelya on 2015-12-11

Related branches

Sprints

(?)

Work Items

Work items:
SPEC: DONE
A "dummy service app" example to demo how a duplicated RPC call delivery shall be handled by the "app side": TODO

This blueprint contains Public information 
Everyone can see this information.