[erlang-questions] question re. message delivery

[Oliver Korpilla]

Hello, Miles.

Not sure if that is the best example.

Trusting blindly in delivery order can cause problems, so financial transactions could for example handled by doing transactions on Mnesia. These transactions should have checks within them that abort the transaction if it cannot be applied. Also, the system does not rely on the arrival of messages, only that each query is responsible for doing its own checking - like disallowing account balances below zero and hence rejecting (or flagging) such a transaction. Ordering problems can then be solved by retries, for example.

If you start to rely on message order and guaranteed delivery, standard Erlang messaging is not a suitable system. IIRC, RabbitMQ guarantees delivery _if possible_. If you enable this mode every message is cached until its processing is acknowledged. Excuse my lack of specifics or any inaccuracy but I have this info from somebody else demonstrating their distributed system to a group I was in.

Guarantees come at a cost. If delivery (if possible) must be assured and non-delivery must be detected, you have to pay that cost somewhere.

Cheers,
Oliver
 
 

Gesendet: Dienstag, 26. September 2017 um 20:10 Uhr
Von: "Miles Fidelman" <mfidelman@REDACTED>
An: "Matthias Lang" <matthias@REDACTED>
Cc: erlang-questions@REDACTED
Betreff: Re: [erlang-questions] question re. message delivery

On 9/26/17 10:05 AM, Matthias Lang wrote:
On 26. September 2017, Miles Fidelman wrote:


Miles, do you have some concrete examples of situations where you're
worried about messages disappearing? Here's one from me: process 1
sends two messages to process 2. The messages are A and B,
respectively. Process 2 sends an ACK for message B back to process
1. For single-node Erlang, if message A disappears then that is a
bug. I'll let others reason about distributed Erlang.
Sure.  Bank transactions.  Edits to a document.  Dispatch commands to a
vehicle.
Those are not what I consider concrete examples.
How concrete do you need.  There are lots of systems where one needs reliable, ordered message delivery.  One generally implements an acknowledgement, but those can be unordered.

Let's say that a transaction is a test-and-set on a value.  With acknowledgement sent after transaction is executed.

Send transactions 1,2,3,4,5

If message delivery is ordered & guaranteed, then an acknowledgement from 5 guarantees that transactions 1-4 were performed, in order, even if some of the acknowledgements were not received.

If, either, a message can get dropped, or it can get delivered out of order, then one needs a protocol on top of basic message delivery to wait for an acknowledgement of each and every message before sending the next. 

There are multiple approaches to implementing a reliable messaging protocol.  What approach would work best somewhat depends on the kinds of failure modes one has to deal with (i.e., the services provided by the next layer down).

Miles
-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra
_______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions