Make the ack-then-process option configurable

Registered by Bogdan Dobrelya

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

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.