Updating tickets (#749, #750, #751, #752, #753, #754, #755, #763, #764, #766, #767, #768)

What does this one mean? Is it crucial for 2.0 or can it be moved?

Exactly as the subject line says. Remote sends and in proc sends should have the exact same semantics, and those should be specced and tested. Crucial.

I understand the title now. I agree.

Proposal based on last week’s discussions:

- tell never throws an exception
- not even when trying to queue while still STARTING: message will get queued (necessary for send-to-self from constructor)
- no guarantees apart from preservation of ordering per sender (should also work if there is happens-before between sends from different sources, right?)

Shall I create a ticket for the second point, or do we track it here?

So far:

- No guaranteed delivery
Akka does not guarantee that a message will be delivered
Akka does not guarantee that a message will be processed

- At-most-once
Actual transports may provide stronger semantics, but at-most-once is the semantics you should expect

- Ordering is preserved on a per-sender basis
A1 sends messages M1, M2, M3 to A2
A3 sends messages M4, M5, M6 to A2
This means that:
1) If M1 is delivered it must be delivered before M2 and M3
2) If M2 is delivered it must be delivered before M3
3) If M4 is delivered it must be delivered before M5
4) If M5 is delivered it must be delivered before M6
3) A2 can see messages from A1 interleaved with messages from A3
4) Since there is no guaranteed delivery, none, some or all of the messages may arrive to A2

wip-768-message-send-semantics